ci: gate on lockfile drift and regenerate uv.lock for 1.10.1

[Bre77]

Intent

• uv.lock's root package version had drifted behind pyproject.toml (1.10.0 vs the current 1.10.1), and this has happened twice in the last four releases (also v1.9.0 vs a v1.8.2 lock)
  • No workflow ever asserts the lockfile against pyproject.toml — ci.yml and release.yml all run plain uv sync, which silently regenerates the lock in the runner and continues green
  • PyPI is unaffected: the wheel builds from pyproject.toml, not uv.lock. The risk is to contributors running uv sync --locked, who get rejected against a drifted checkout
• Fix: add --locked to the existing uv sync steps in ci.yml (lint + test jobs) and release.yml (gate job), rather than adding a separate uv lock --check step or a parallel job — it reuses the sync call every job already makes instead of growing new CI machinery
• Regenerated uv.lock via uv lock so the root package reads 1.10.1
• Documented the uv lock regeneration step in AGENTS.md's Release Process section, alongside the existing version-bump instructions

Tested the gate: reverted uv.lock's root package version to 1.10.0 locally and ran uv sync --locked — it failed with error: The lockfile at uv.lock needs to be updated, but --locked was provided. Restored the correct lock and reran; it passed cleanly.