chore(deps): bump deps past semver-major and pin author digests

[dekobon]

Advances the dependency graph past the semver-major line Dependabot is
configured to ignore, refreshes every lockfile, and closes a test gap
the review of that work turned up.

make pre-commit passes: 5163 Rust tests (5161 on main, plus
exactly the two new pins) and 363 passed / 1 xfailed on the Python
side. All 26 complexity-class probes stay within bounds.

Dependencies

Tier	Change
Lockfiles	125 packages in the root workspace, 13–18 in each of the six excluded crates
semver-major	gix 0.83 → 0.86, sha2 0.10.9 → 0.11.0, hmac 0.12.1 → 0.13.0, num-derive 0.4 → 0.5, clap_mangen 0.2 → 0.3, jsonschema 0.46 → 0.49 (dev)
Pinned-by-policy	pyo3 0.29.0 → 0.29.2 (+ pyo3-build-config) — a patch inside the minor the manifest comment guards
Python	uv lock --upgrade + regenerated hash-pinned exports: mypy 2.1 → 2.3, pyright 1.1.409 → 1.1.411, pytest 9.0.3 → 9.1.1, maturin 1.13.3 → 1.14.1

Grammars are untouched. All twenty external grammar crates and the
tree-sitter runtime are already at their latest published versions,
so none of the usual snapshot churn applies.

The whole major-bump set cost three source lines: one import (hmac
0.13 splits KeyInit out of Mac) and two mypy 2.3 tightenings in
test annotations.

No public-API change. No gix or RustCrypto type appears in a
public signature, so STABILITY.md is unaffected.

Two manifest comments were stale and are corrected. The sha2 pin
claimed to match a version "locked transitively via grammar crates";
cargo tree shows the root crate is now its only dependent. The hmac
comment claimed digest 0.10 added no new trait version, when
actix-http had already brought digest 0.11 into the graph via
sha1 0.11 — which is the island sha2 and hmac now join.

Test gap closed

Reviewing the sha2 / hmac bump surfaced something worth fixing on
its own. Every assertion on AuthorId::hashed and
AuthorHashKey::apply was relational — it compared one digest
against another produced by the same build, so it held whatever the
hash library emitted. A repo-wide search found no 64-hex literal
anywhere.

That is the wrong shape for these two, because their output is a
stored value with cross-version contracts on both sides.
src/vcs/cache.rs writes unkeyed digests to disk and honours them
across version boundaries (CACHE_SCHEMA_VERSION tracks the on-disk
format, not the hash implementation, so a dependency bump does not
invalidate an existing cache), and AuthorId::hashed documents the
emitted digests as stable cross-report pseudonyms.

Expected values are derived from Python's hashlib / hmac, so the
new tests assert conformance to SHA-256 and RFC 2104 rather than
agreement with our own implementation.

Verified by perturbation, per .claude/rules/testing.md:

Perturbation	Failures across the lib suite
SHA-256 pre-image changed	2 — both new pins, nothing else
HMAC pre-image changed	1 — the keyed pin, nothing else

That second column is the finding, measured rather than argued: no
pre-existing assertion noticed a changed hash output. The digests did
not in fact move here — SHA-256 is SHA-256 — but nothing in the suite
could have told us.

Performance

Measured by interleaved paired A/B per
docs/development/benchmarking.md#interleaved-ab, since the host was
at load 6–8 throughout. Corpus slice: 177 files, 903 KiB, 14 languages.

No detectable change. A 7-round sweep left corpus/parse/tree-sitter
slower in 6 of 7 rounds, which had a mechanism worth chasing — parsing
is pure grammar C and cc moved 1.2.62 → 1.4.0, recompiling every
grammar. It did not replicate: at 15 rounds with corpus/walk/nom as a
control, parse was 10/15 slower with a 1.3% median (chance), and the
control's spread (0.84–1.27) was wider than the subject's entire
range (0.95–1.08). The measurement floor on this host exceeds any
effect present.

If you run a single cargo bench, criterion will print a
Performance has regressed line against its stored baseline. That is
the sequential-comparison artifact the benchmarking doc warns about —
two runs minutes apart on a loaded host. The paired result above is the
one to trust.

Deliberately not included

• ruff stays capped at <0.16. ruff 0.16.0 expanded the default
  rule set from 59 to 413 rules; because the config selects with
  extend-select, the effective set jumps 265 → 501 on identical
  config, pulling in 28 families including PL — which the comment
  directly above extend-select says is deliberately omitted. The fix
  is a one-line config change (extend-select → select, verified to
  give 268 rules and a clean ruff check under 0.16.1), but it is a
  separate decision. Filed as deps(py): adopt ruff 0.16 by pinning the rule set with select #1222.
• clap_mangen 0.3 reorders the SYNOPSIS, moving the required
  <-t|--type> after the optional flags in man/bca-count.1 and
  man/bca-find.1. Two lines; kept deliberately.

Addendum: CI dispatch trigger

Reviewing this PR's Codecov report turned up an unrelated problem worth
fixing while it is visible.

Codecov compares a PR against the most recent ancestor that carries a
report. Main's head d818e306 has zero check-runs and therefore no
coverage upload, so this PR is baselined against f71bcc7d, eight
commits behind. The +64 lines / +66 hits / -2 misses in the Codecov
comment are almost entirely those eight commits — two of which are real
source fixes (fix(nargs): count Objc block params through count_args,
fix(gates): decide diagnostic-prefix state with a lexer) — and not
this PR, whose only production source change is an import line with no
instrumented regions. Patch coverage is correctly reported as ø.

ci.yml was the only workflow here without workflow_dispatch, so the
sole remedy for a missed main run was to land another commit. Added.

Note it cannot be used to fix this instance until it is on the default
branch — workflow_dispatch resolves against main. Merging this PR
also produces a fresh main run, which re-baselines Codecov either way;
the trigger is for the next time.

Two things checked and found fine, recorded so they are not
re-investigated:

• Test files are not in the coverage denominator. Codecov's ignore
  lists **/tests/**, which does not match this repo's sibling
  <module>_tests.rs files under src/ (46 files, ~25,920 lines). The
  Codecov API reports zero of them present, so cargo-llvm-cov
  attributes no regions to them. Excluding them recomputes 98.33% to
  98.34%. No change warranted.
• The patch-vs-project gap is not a defect. Patch measures only
  lines the PR touches; project measures the tree. The 1.67% is
  pre-existing uncovered code in untouched files.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.33%. Comparing base (f71bcc7) to head (881d942).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1223   +/-   ##
=======================================
  Coverage   98.33%   98.33%           
=======================================
  Files         278      278           
  Lines       71979    72043   +64     
  Branches    71549    71613   +64     
=======================================
+ Hits        70779    70845   +66     
+ Misses        790      788    -2     
  Partials      410      410           

Flag	Coverage Δ
python	100.00% <ø> (ø)
rust	98.32% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/vcs/identity.rs	100.00% <ø> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.