ci: gate on uv.lock staleness so CI's typecheck env can't drift from the lockfile

[cdeust]

Summary

Fixes #251.

uv.lock currently resolves tree-sitter-language-pack 1.13.5 — the same
version CI's typecheck job installs via the hash-pinned,
uv.lock-derived requirements/ci-typecheck.txt — so
uv sync --locked --all-extras && pyright mcp_server/ already reports
0 errors, 0 warnings, 0 informations today (evidence below). But nothing in
CI verified uv.lock itself stays current with pyproject.toml's declared
constraints; the existing "Check hash-pinned requirements match uv.lock"
step only compares the committed requirements/*.txt against whatever
uv.lock currently says — a stale lock and its stale export agree with
each other and that check stays green.

That gap is exactly how the original divergence shipped: Dependabot's deps
PR #218 widened tree-sitter-language-pack's upper bound in
pyproject.toml (<1.7 -> <1.14) but touched no other file — its pip
ecosystem entry rewrites the version specifier only, it does not re-run
uv lock. uv.lock kept resolving 1.6.2 (still valid under the wider
range — uv lock's incremental resolution prefers an existing pin over the
newest compatible one), so a contributor's uv sync --locked and CI's
then-unconstrained pip install -e ".[...]" silently diverged on the same
commit: 1 pyright error locally, 0 in CI.

Fix

Add a uv lock --check step to the lint job, running before the existing
hash-pinned-requirements check, so any future pyproject.toml constraint
change that isn't accompanied by a lock refresh fails the build at commit
time instead of resolving silently differently per install path.

Reproduction that the new gate would have caught the original drift

Checked out pyproject.toml + uv.lock as of 9e293baa (the commit right
after #218 widened the range) into a scratch directory:

$ uv lock --check
Using CPython 3.13.11
Resolved 196 packages in 186ms
The lockfile at `uv.lock` needs to be updated, but `--check` was provided. To update the lockfile, run `uv lock`.
$ echo "exit=$?"
exit=1

Reproduction that the current tree is already clean (issue's AC #1)

$ uv lock --check
Resolved 195 packages in 2ms
$ pyright --venvpath <shared .venv's parent> mcp_server/
0 errors, 0 warnings, 0 informations

(pyright 1.1.410, the CI pin; tree-sitter-language-pack 1.13.5 installed,
matching both uv.lock and CI's requirements/ci-typecheck.txt.)

$ pytest tests_py/core/test_ast_parser.py -q
19 passed in 0.46s

Boy-scout fix (same file, same dependency)

Corrected a stale comment on the tree-sitter-language-pack pin: it claimed
<1.7 (no such PyPI release exists — versions jump 1.6.3 -> 1.8.0) and
an AttributeError on parser.parse(...) traced to upstream issue #141
(get_parser/get_language API consistency). That upstream break only
affects callers building tree_sitter.Parser(get_language(name))
themselves — the changelog names get_parser(name) directly (what
ast_parser.py:88 calls) as the unaffected, documented path. Verified
against the actually-resolved 1.13.5 above (19/19 tests passing).

Deferred (outside this change's blast radius, filed)

Running actionlint against .github/workflows/ci.yml as an extra
precaution on the new step surfaced pre-existing SC2015/SC2034 shellcheck
findings in the unrelated test job's PostgreSQL-provisioning retry loops
(lines 55, 56, 64) — not reachable by any build/lint/test step this PR's own
change triggers, and not part of this repo's own gates (no actionlint
reference anywhere in .github/). Filed as
#267 per coding-standards.md §14.3
rather than folded in here (also avoids adding merge-conflict surface to the
same file across several other in-flight worktree branches).

Completion ledger

Path in diff	Evidence
New Check uv.lock matches pyproject.toml step passes on current tree	uv lock --check → Resolved 195 packages in 2ms, exit 0
New step fails on the historical drifted state	reproduced against 9e293baa's pyproject.toml+uv.lock → exit 1, "needs to be updated"
actionlint reports no new findings from the added step	ran before/after; identical 4 pre-existing findings at line 45 (test job), none near the new step
pyproject.toml comment correction doesn't change resolution	uv lock --check and generate_pip_constraints.py --check both pass unchanged after the edit (comment-only)
pyright 0-diagnostic gate holds under the resolved (1.13.5) environment	pyright --venvpath ... mcp_server/ → 0 errors, 0 warnings, 0 informations
ast_parser.py's get_parser(...).parse(...) call is functionally sound under 1.13.5	pytest tests_py/core/test_ast_parser.py -q → 19 passed
Edited TOML is syntactically valid	tomllib.load() round-trip
Edited YAML is syntactically valid	yaml.safe_load() round-trip

Not done in this PR (by design, not deferral)

mcp_server/core/ast_parser.py:88's SupportedLanguage literal narrowing
(one of the three "or" options in #251's AC, and the subject of the
overlapping #249/#253 duplicate issues) is left untouched: another in-flight
worktree branch is already addressing it under #249, and #251's own
acceptance criteria is satisfied by the CI-reproducibility fix above (an
"or", not an "and").

Test plan

• uv lock --check — clean on current tree, fails on the pre-sec: hash-pin every dependency install and add coverage-guided fuzzing #244 drifted tree
• pyright mcp_server/ — 0 diagnostics against the resolved 1.13.5 environment
• pytest tests_py/core/test_ast_parser.py — 19/19
• python scripts/check_doc_claims.py — OK
• python scripts/generate_repo_badges.py --check — OK
• python scripts/generate_pip_constraints.py --check — OK (unaffected by the comment-only pyproject.toml edit)
• actionlint .github/workflows/ci.yml — no new findings (pre-existing findings filed as ci.yml PostgreSQL setup retry loops: SC2015/SC2034 shellcheck findings (test job, lines 55-56, 64) #267)
• CI run on this PR (report will be updated with the actual run result — not merging until green)

https://claude.ai/code/session_012Yu6EnWspTfqHoGkExyS6u