ci: fail release PR integrity on a lagging Cargo.lock

[ScriptedAlchemy]

Release PR #2288 (1.0.0-beta.56) merged with a Cargo.lock still at 1.0.0-beta.55, breaking every --locked build on master (fixed by #2311).

Why the lockfile step was skipped: release-please regenerates the release branch as a single fresh commit on every master push, which drops the previous chore(release): update root lockfile commit. The refresh step does run on updates (prs_created is true for updated PRs too in release-please-action v5), but only once the Release Please run gets a runner. The PR stays ready for review after its first refresh, so every regeneration opens a window with a lagging lock. #2288's only commit was a regeneration pushed 83 seconds before the merge, with the runner starved.

Change: scripts/check-release-pr-integrity.sh, which the Release PR integrity workflow loads from the trusted base, now compares each local package's manifest version (resolving version.workspace = true) with its source-less Cargo.lock entry and fails on any mismatch. It reads TOML with python3 tomllib and needs no cargo or vendored sources. The same script is the local check before a manual release merge (scripts/check-release-pr-integrity.sh origin/master HEAD with the PR head checked out). CI's existing check-release-pr-integrity.sh HEAD HEAD step also runs it on every PR, which catches a lagging lock on master.

Evidence (local):

• tests/release_pr_integrity_test.sh adds the literal beta.55/beta.56 workspace case. It passes with this guard and fails against origin/master's guard: a lock lagging the workspace version must fail: expected failure, but the command succeeded.
• Real repo, with origin/master's pre-build: sync Cargo.lock to the 1.0.0-beta.56 workspace version #2311 lock: exit 1

  tracedecay: Cargo.toml 1.0.0-beta.56, Cargo.lock 1.0.0-beta.55
  tracedecay-cli: Cargo.toml 1.0.0-beta.56, Cargo.lock 1.0.0-beta.55
  tracedecay-project: Cargo.toml 1.0.0-beta.56, Cargo.lock 1.0.0-beta.55
  

  With the synced lock: exit 0.
• actionlint on release-pr-integrity, release-please, and ci workflows: exit 0.

Still open: master has no branch protection or required checks, so a failing Release PR integrity flags a release PR but does not block its merge. Making the check required is a repository-settings decision.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 017bcc1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-27T09:46:07.380703Z	017bcc1	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 017bcc1b56

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Validate lock consistency instead of only package versions

When the allow-listed root Cargo.toml changes a dependency constraint, patch, or resolver setting such that the existing resolution is stale, this loop still succeeds as long as each local package retains the same version. The release integrity check can therefore approve a lockfile that Cargo must update, recreating the broken locked-build outcome it is intended to prevent; validate the checked-out manifests and lock through Cargo's resolver rather than a name/version source-shape scan.

AGENTS.md reference: AGENTS.md:L172-L177

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Describe the invariant instead of the historical incident

This comment anchors a durable regression test to a specific master incident and beta release, so it becomes stale release-history narration rather than explaining why the fixture matters. Rephrase it around the invariant that workspace-inherited versions must agree with their lock entries, leaving the incident provenance in commit history.

AGENTS.md reference: AGENTS.md:L195-L197

Useful? React with 👍 / 👎.