build: require Python 3.10 for the prqlc Python package

[prql-bot]

The prqlc Python package declares requires-python = ">=3.9", but 3.9 is untested (noxfile.py runs 3.10 and 3.12) and end-of-life since October 2025 — and the stale claim has been breaking Dependabot's uv updater for the binding every day since 2026-08-07, so no Python dependency update has reached it in 16 days. This bumps the floor to >=3.10 and regenerates uv.lock. Verified by reproducing Dependabot's exact resolver error locally and confirming it resolves after the change.

The failure

Dependabot's uv in /prqlc/bindings/prqlc-python job has failed on every run since 2026-08-07 — 16 consecutive daily runs, most recently 32506942984:

Handled error whilst updating pytest: dependency_file_not_resolvable
× No solution found when resolving dependencies for split (markers: python_full_version == '3.9.*'):
╰─▶ Because the requested Python version (>=3.9) does not satisfy Python>=3.10
    and pytest==9.1.1 depends on Python>=3.10, we can conclude that
    pytest==9.1.1 cannot be used.
    And because prqlc:dev depends on pytest==9.1.1 and your project requires
    prqlc:dev, we can conclude that your project's requirements are unsatisfiable.

Dependabot proposes a candidate as an exact pin (pytest==9.1.1) across the whole declared range. pytest 9 requires 3.10+, so the python_full_version == '3.9.*' fork is unsatisfiable and the whole job aborts — taking every other dependency in the group with it. uv names the fix in its own hint: "Consider using a more restrictive requires-python value (like >=3.10)."

Note this is invisible to a normal uv lock, which is free to fork the resolution (pytest v8.4.2 -> v8.4.2, v9.1.1) and succeeds. Only the exact-pin form Dependabot uses fails.

Reproduction and verification

Simulating Dependabot by replacing the dev group's pytest >= 7 with pytest==9.1.1, against the current requires-python = ">=3.9":

× No solution found when resolving dependencies for split (markers:
│ python_full_version == '3.9.*'):
╰─▶ Because the requested Python version (>=3.9) does not satisfy
    Python>=3.10 and pytest==9.1.1 depends on Python>=3.10, we can conclude
    that pytest==9.1.1 cannot be used.
...
hint: The `requires-python` value (>=3.9) includes Python versions that are not
supported by your dependencies (e.g., pytest==9.1.1 only supports >=3.10).

That reproduces the CI log character for character. With only requires-python changed to >=3.10 and the same simulated pin:

Resolved 11 packages in 443ms
Updated pytest v8.4.2 -> v9.1.1

Why 3.10 is the right floor

• Nothing tests 3.9. noxfile.py's VERSIONS is ["3.10", "3.12"], and test-python.yaml sets up exactly those two interpreters. The >=3.9 claim has never been exercised.
• Python 3.9 reached end-of-life on 2025-10-31.
• This is not a break for existing users: pip on 3.9 keeps resolving the last release that declared support, it just stops picking up new ones.

Scope notes

• uv.lock also moves pytest 8.4.2 → 9.1.1 and drops two now-redundant python_full_version markers. That is the mechanical consequence of removing the 3.9 fork, not a separate decision — and CI already runs pytest 9, because noxfile.py installs pytest>=7 directly rather than syncing from the lock.
• The abi3-py37 feature on pyo3 is deliberately left alone. It sets the C ABI floor and the wheel tag, which is a separate concern from the metadata floor; cp37-abi3 wheels install fine on 3.10+.
• If you'd rather keep the 3.9 claim, the alternative is constraining the dev group instead (pytest<9 for python_version<'3.10'), which unblocks Dependabot the same way at the cost of a marker-split dev dependency. Say the word and I'll switch it.

Found by

The daily review-runs sweep, checking why rustls-webpki's security-update job failed this morning. That turned up a wider pattern nothing in the loop currently watches: 10 open Dependabot alerts (oldest 2026-04-24) and four distinct update jobs failing — uv (16 days, this PR), cargo … for pyo3 (security_update_not_possible, 0.27.2 installed vs 0.29.0 required — a genuine 0.27→0.29 migration, out of scope here), cargo … for rustls-webpki (also update_not_possible, but it reaches Cargo.lock only via tiberius/duckdb behind test-dbs/test-dbs-external, so it is not in any published artifact), and npm_and_yarn … for dompurify. Details are in the review-runs tracking issue #6123; this PR is the one piece with a small, self-contained fix.