ci: test the interpreter we actually ship (3.12 + 3.14 matrix)

[berntpopp]

The gap

docker/Dockerfile ships python:3.14-slim, but the CI test job ran only on
Python 3.12. container-ci and conformance exercise the image on 3.14; the
test suite never ran on it. A 3.14-only stdlib or typing regression would have
shipped uncaught.

The fix

The quality job now runs a ["3.12", "3.14"] matrix — a matrix, not a swap:

• 3.12 is the declared requires-python floor. Drop it and the floor is a
  false claim.
• 3.14 is what actually reaches production.

The coverage gate still runs once (on 3.14, push to main), so the cost is
one extra fast test run per event, not two coverage runs.

UV_PYTHON is load-bearing

The matrix alone would have been a green lie. uv resolves its interpreter from
.python-version — pinned to 3.12 for local dev — before it consults
PATH, so actions/setup-python installing 3.14 changes nothing: both legs
would build a 3.12 environment and the "3.14" leg would test the floor twice.
The job therefore exports UV_PYTHON: ${{ matrix.python-version }}, which
outranks .python-version and applies to every uv run inside make ci-local,
not only the explicit uv sync.

Kept honest by a guard

New tests/unit/test_ci_python_matrix.py asserts the matrix contains the
requires-python floor and the Dockerfile's FROM python:<x.y>-slim, that
UV_PYTHON is wired to the matrix, and that the coverage gate runs once rather
than per leg. A future base-image bump that is not mirrored into CI now fails
instead of silently re-opening the blind spot.

requires-python, ruff target-version and mypy python_version are
deliberately unchanged at 3.12.

Verification

make ci-local locally on both interpreters — 478 passed, 2 skipped on each
(the 2 skips are the live conformance probes, which need a running server).

🤖 Generated with Claude Code

https://claude.ai/code/session_01EUS8yK2hqkNpfoTxFR4RPR