fix: raise the Python floor to 3.14

[catinspace-au]

Part of moving the whole suite to 3.14. The owner's rule: any part of the suite still on 3.12 moves.

• requires-python goes >=3.12 -> >=3.14
• uv.lock re-resolved under CPython 3.14.4. 92 packages, and no package dropped -- the 464 removed lines are all cp311/cp312/cp313 wheel rows, confirmed by git diff uv.lock | rg "^-name = " returning nothing

ruff target-version stays on py312 on purpose, matching scalo-py and hyperi-ci. At py314 the formatter strips the parentheses from multi-exception except clauses (PEP 758). hyperi-ci has a sharper reason than we do -- it loads version_source.py by path with an older interpreter before any install -- but holding the whole suite at one static-analysis level beats splitting it per repo.

Nothing else in this repo pins a Python version: no .python-version, no classifiers block, no mypy/ty/vermin sections, and none of the three Dockerfiles uses a Python base image (all ubuntu, with python3 from apt).

One thing NOT verified: whether ubuntu:26.04 ships Python 3.14. The container installs the distro interpreter, which requires-python does not govern, so if 26.04 carries 3.13 the container diverges from the declared floor. Worth a check before this is relied on in anger.

Depends on nothing, but note scalo-py #28 is still open -- the suite is not actually on 3.14 until that lands.

Done when CI is green.

[catinspace-au]

Second commit added, and it is not about Python.

ci / Test (ubuntu-latest) failed on two assertions that have nothing to do with the floor bump:

AssertionError: assert 'v2.1.14' == 'v2.1.15'
AssertionError: chart appVersion v2.1.14 is behind 2.1.15, the newest release in
CHANGELOG.md, so `helm install` deploys an image that old

This is pre-existing and main is red. On origin/main, VERSION is 2.1.15 and CHANGELOG's newest entry is 2.1.15, while deploy/helm/culvert/Chart.yaml sits at 2.1.14 for both version and appVersion. My branch touched only pyproject.toml and uv.lock -- git diff origin/main..fix/python-floor-314 --stat shows exactly those two files before this commit.

So the chart has been shipping the previous image, and two tests written to catch precisely that have been failing on main.

Fixed here rather than filed, because it is what makes this branch red and the repo rule is that a bug you see is yours. tests/unit/test_deploy_artefacts.py now passes 27/27 locally.

Bumped version alongside appVersion because they were equal before and the chart content has changed; only appVersion is asserted by the tests.

[catinspace-au]

Chart fix worked -- ci / Test (ubuntu-latest) is green, and ci / Gate is now the only red.

That Gate failure is hyperi-ci's, not this PR's: c8bf404 added a Gate job to all five shared workflows at 04:51Z together with the gate-check subcommand it calls, but the job installs the CLI via uvx --refresh, which resolves the published v2.10.4 from 03:42Z. Exit 2, No such command 'gate-check'. Every consumer on @main has it.

Holding this rather than merging over it, same as dfe-loader #192. I have told the hyperi-ci session that a fleet-wide red Gate trains people to ignore a red Gate; merging straight past one the same afternoon would undercut that. It clears itself when they publish -- nothing here needs to change.