Install CI dependencies from uv.lock #2128

Problem

PR CI does not install from uv.lock, so a new upstream release can change what every open PR is tested against.

On 2026-10-03, policyengine-core 3.32.16 reached PyPI at 20:59Z. It changed Holder to call InMemoryStorage.put(..., derived=...), and every open PR's Test job then failed in policyengine_uk/tests/code_health/test_cached_arrays_not_written_in_place.py. #2125 fixed that fixture. The cause is still there.

The Test job in pr_code_changes.yaml (and in code_changes.yaml on main):

1. runs uv pip install -e .[dev] --system, which resolves the newest releases. Run 37160633200 installed policyengine-core==3.32.16;
2. runs uv pip install policyengine --system, which nothing imports, and which downgraded microdf-python 1.5.11 → 1.3.10 in that run;
3. runs uv sync --extra dev, which builds the locked .venv (policyengine-core==3.32.13);
4. runs make test from the system Python. The locked .venv is never used.

Lint (uvx ruff) and the docs build have the same problem.

There is a second problem. uv.lock records this package's own version as 2.109.5, while pyproject.toml is at 2.113.0. The versioning workflow bumps pyproject.toml only, so uv sync --locked fails on main today.

Fix

1. The release bump updates the lock's own version line along with pyproject.toml, and the versioning job runs uv lock --check before committing.
2. Lint, Test and the docs build run uv sync --locked --extra dev and uv run --no-sync …. The Python 3.11–3.14 smoke-import matrix keeps installing the newest releases, so upstream breaks still show up early.

These land as two PRs, in that order. The second does not touch the lock's version line, so a version bump on main between push and merge can't break its --locked check.