ci: keep Cargo.lock in step with releases and gate CI on --locked

[alukach]

What I'm changing

release-please bumps every workspace crate's version in Cargo.toml on each release, but nothing updates Cargo.lock. The lockfile has been going stale on every release: main carried 0.7.1 entries against a 0.7.2 manifest until some later cargo invocation happened to rewrite the file. CI never noticed because no job runs with --locked, so cargo quietly regenerated the lock on each run.

This PR makes the release PR update the lock itself and makes CI fail on a stale lock.

How I did it

• release-please-config.json: one more toml extra-file targeting Cargo.lock with JSONPath $.package[?(!@.source)].version. In a lockfile, only workspace members lack a source field (registry and VCS dependencies always carry one), so the filter selects exactly the ten workspace crates and nothing else, and a newly added crate is covered without a config change. release-please's TOML updater uses jsonpath-plus, which supports filter expressions, and edits values in place without reformatting the file.
• .github/workflows/ci.yml: the Cargo Check job runs cargo check --locked. This is the gate; a stale lockfile, from a release or from a dependency change committed without its lock update, now fails instead of self-healing.
• CONTRIBUTING.md: notes that the lockfile is committed and checked, and that the release PR maintains the workspace entries.

Verified locally by running release-please's actual GenericToml updater (v17.9.0) against this repo's Cargo.lock: it changed the ten workspace entries and no others. Then simulated a release end to end: bumped Cargo.toml to 0.7.3 the way the release does, confirmed cargo check --locked fails with the stale lock, ran the updater, and confirmed it passes.

Test plan

• release-please GenericToml updater run against Cargo.lock with the filter: 10 entries changed, all workspace members
• cargo check --locked on main as-is: passes
• cargo check --locked after a simulated version bump with a stale lock: fails; after the updater rewrites the lock: passes

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 1m 13s —— View job

---

Review complete ✅

• Gather context (PR diff, changed files)
• Review release-please-config.json change
• Review .github/workflows/ci.yml change
• Review CONTRIBUTING.md change
• Ponytail pass for over-engineering
• Post final review

---

✅ No blocking issues — safe to merge.

Verified independently: Cargo.lock currently has 333 [[package]] entries, 323 with a source field and exactly 10 without — matching the PR's claim that the $.package[?(!@.source)].version filter selects exactly the ten workspace members. The --locked addition in .github/workflows/ci.yml:50 is correctly scoped to gate the check job, which is sufficient to fail CI (and thus block merge under normal branch protection) without needing to touch every job.

One non-blocking caveat worth noting: the filter's assumption ("only workspace members lack source") holds today but isn't universally true for all Cargo.lock configurations — a future local path dependency added outside the workspace (e.g. a [patch] override) would also lack source and get silently swept into the version bump. Not an issue with the current repo state, just something to keep in mind if such a dependency is ever introduced.

Simplify (ponytail)

Nothing to flag — the diff is already minimal (one filter-based lockfile entry instead of per-crate entries, a single-line CI flag, two lines of docs).

---

💰 Estimated review cost: $0.29 · 1m13s · 16 turns

[github-actions]

🚀 Latest commit deployed to https://multistore-proxy-pr-158.development-seed.workers.dev

• Date: 2026-09-25T15:54:22Z
• Commit: 6abf652