Align supported Python versions with dependency and tooling compatibility

[vndee]

Context

pyproject.toml currently declares requires-python = ">=3.10,<4.0", but a local uv run pytest -q selected Python 3.14 and failed before tests ran while building tiktoken==0.9.0 due to missing Rust/wheel support. The same suite passes on Python 3.13.

Why this matters

The package advertises compatibility far beyond what the current dependency/tooling stack is known to support. Users on Python 3.14 can hit setup failures even though the project metadata says the interpreter is allowed.

Acceptance criteria

• Decide whether Python 3.14 is supported now.
• If not supported, cap requires-python appropriately and document the supported range.
• If supported, add Python 3.14 to CI and update dependencies/tooling so the suite installs and passes.
• Ensure local development setup uses a supported interpreter by default where possible.

Evidence

• Python 3.13: 1069 passed, 2 skipped.
• Python 3.14: dependency build failed while building tiktoken==0.9.0.

[github-actions]

The GitHub issue highlights a misalignment between the Python versions specified in the pyproject.toml file (>=3.10,<4.0) and the actual compatibility of dependencies and tooling, particularly with Python 3.14. A local test run on Python 3.14 failed during the build of a dependency (tiktoken==0.9.0) due to missing Rust/wheel support, while it passed on Python 3.13. This creates a discrepancy between the advertised and actual compatibility, potentially leading to setup failures for users on unsupported Python versions. To address this, the project needs to either limit the requires-python field for accuracy or ensure support for Python 3.14 by updating dependencies and integrating it into CI testing. Additionally, the local development setup should default to a supported Python version to prevent similar issues.