Fix phantom version bump in release-readiness

[Mikola Lysenko (mikolalysenko)]

Problem

release-readiness failed falsely on PR #1489 after it merged main across the 5.0.1 release (run 38444545888):

Version bump PR detected (5.0.0 -> 5.0.1); running the full release gate.
##[error]tag v5.0.1 already exists at 2e0a6b9e... — bump to a new version

The PR didn't bump anything. The event's pull_request.base.sha was 285a5e8 (main before the release, 5.0.0), but the tested merge commit c59161a was "Merge 36b49c6 into d4af25a" (current main, 5.0.1). That turned ci-ok red for a version bump that wasn't real. The next push went green. The same thing can happen to any open PR that merges main after a release lands while the event payload's base lags.

Root cause

github.event.pull_request.base.sha isn't guaranteed to be the commit refs/pull/N/merge was built on. It can lag behind the base branch.

Fix

Read the base from the first parent of the checked-out merge commit (git cat-file -p HEAD, which works in the depth-1 checkout) and drop the BASE_SHA env. That parent is exactly the base the tested tree was merged onto. Real version-bump PRs (release/v*) still see main's old version as the parent and run --tag-check. The release-sync path is unchanged.

Proof

• Local repro: built a merge ref whose base had moved, fetched it with --depth 1 as actions/checkout does, and the parsed first parent matched the moved base tip, which then fetched by SHA.
• On Fix scans missing renamed yarn copies (#939, #1236) #1489's failing run, the first parent is d4af25a (5.0.1). That means no bump, so it runs --sync-only, which is what the following green run did.
• YAML parses. actionlint and zizmor aren't available in this sandbox.

Where tests run

Nothing removed or moved. Job and check names are unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LgS1BwdcQfkDYXqbXL8uUA

---

Generated by Claude Code

---

Note

Low Risk
CI-only change to how the release-readiness gate picks the base commit; no runtime or release publish behavior changes.

Overview
Fixes false version-bump failures in the release-readiness CI job when a PR merges main after a release lands.

The job used github.event.pull_request.base.sha to read the base Cargo.toml version, but that SHA can lag behind the commit refs/pull/N/merge was actually built on. That made merges-across-release look like 5.0.0 → 5.0.1 bumps and triggered --tag-check even though the PR did not change the version.

Change: drop the BASE_SHA workflow env and set it from the first parent of HEAD (the checked-out merge commit) via git cat-file, then fetch that object for the version comparison. Real bump PRs and the release-sync path are unchanged.

^{Reviewed by Cursor Bugbot for commit 64211d4. Configure here.}

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 64211d4. Configure here.}