Package a Python project for real distribution with pyproject.toml

Package the project below for real distribution — not a script that only runs from inside its own folder because of an accident of sys.path, not a setup.py from a five-year-old tutorial.

PROJECT
A small library called "orderkit" for parsing and validating e-commerce order exports.

RUNTIME DEPENDENCIES
pydantic>=2.9, pandas>=2.2

DISTRIBUTION TARGET
internal use via a private index, not public PyPI

VERSIONING SCHEME
Semantic versioning starting at 0.1.0, bumped manually per release, no pre-1.0 API stability guarantee.

REQUIREMENTS
1. Use a src/ layout (src/<package_name>/..., inferring the actual package name from the project description) so the package can't accidentally be imported from the repo root during development, hiding a packaging bug that only shows up after a real install elsewhere.
2. A complete pyproject.toml: [build-system] naming a specific backend (hatchling or setuptools>=68 — say which and why), [project] with name, version (matching Semantic versioning starting at 0.1.0, bumped manually per release, no pre-1.0 API stability guarantee.), requires-python, dependencies pinned with sensible lower bounds, and [project.optional-dependencies] for dev/test tooling (pytest, ruff, mypy) kept separate from runtime deps.
3. If this needs a CLI entry point, define it under [project.scripts].
4. A .gitignore covering build artifacts (dist/, *.egg-info, __pycache__/) and a minimal README.md with install and usage instructions matching internal use via a private index, not public PyPI.
5. If internal use via a private index, not public PyPI is public PyPI, flag what else is needed before publishing — a unique name check, a license file, a long_description sourced from the README, a decision on whether Semantic versioning starting at 0.1.0, bumped manually per release, no pre-1.0 API stability guarantee. needs a pre-release tag for the first publish — rather than assuming it's ready to go.
6. Decide explicitly whether package data beyond .py files (a bundled JSON schema, a template file, static assets) needs to ship inside the wheel — if A small library called "orderkit" for parsing and validating e-commerce order exports. mentions any non-code file the package reads at runtime, configure include-package-data or the backend's equivalent, since a file that exists in the source tree but isn't declared as package data silently vanishes from the built wheel and only fails the first time a real install tries to read it.
7. Confirm requires-python is set to a version floor the code can actually run on, not a value copied from habit — if any syntax or standard-library feature used in the project needs a specific minimum version (structural pattern matching needs 3.10, for instance), the floor must match or be raised, so pip refuses an incompatible install up front instead of failing at import time on an older interpreter.
8. State the exact commands to build and locally verify the package installs cleanly: build it, install the built wheel into a fresh throwaway virtual environment, and import it, before it's ever pushed anywhere.

OUTPUT FORMAT
1. The file tree, including any non-code files that need to ship as package data.
2. The full pyproject.toml.
3. The build-and-verify commands, in order.
4. One sentence confirming requires-python actually matches the language features the code uses.