Check that the committed bundle is up to date on release PRs

[satsukies]

Problem / Use case

The Claude Code / Codex plugin serves the plugin/scripts/bundle.js that is committed in git. npm users get a bundle that the Release workflow rebuilds at publish time. The committed bundle is only regenerated when release-please creates or updates the release PR.

release-please does not update the release PR for commits that are not release-relevant, such as Dependabot Bump ... or ci: commits. If such a commit lands on main after the bundle was last regenerated, the release PR still carries the old bundle:

• Plugin users get the stale committed bundle as soon as the release PR is merged.
• npm users get a bundle rebuilt from the newer main.

For example, if #73 (SDK 1.32.0, zod 4.6.5) had been merged before #80, the 1.5.2 plugin would have shipped SDK 1.31.0 / zod 4.4.3 while npm shipped SDK 1.32.0 / zod 4.6.5. For 1.5.2 the two bundles happened to be identical (same SHA-256), but nothing enforces this.

Proposed solution

Add a freshness check to CI for release PRs (head branch release-please--branches--main--components--deploygate):

• In the bundle-compat job, which already runs npm run bundle on Node 24, add a step that runs only for release PRs and fails when the rebuilt bundle differs from the committed one: git diff --exit-code plugin/scripts/bundle.js.
• The failure message should say how to fix it: update the release PR branch so that the Release workflow regenerates the bundle.
• Non-release PRs and pushes to main must not run this check. The committed bundle is expected to lag behind main between releases.

Notes:

• Pull request CI runs on the merge ref (head + current main), so the check also catches drift from commits that landed on main after the bundle was regenerated, as long as CI re-runs. Before merging a release PR, update its branch if it is behind main.
• When release-please first opens or updates the PR, CI may briefly run on a commit that does not have the regenerated bundle yet. The chore: regenerate bundle.js for release commit that follows re-runs CI, so only the latest run matters.

Alternatives considered

• Publish the committed bundle to npm without rebuilding it. This guarantees npm == git but does not catch a stale committed bundle. It is covered in Allow retrying npm publish for an existing release tag #82, and both changes complement each other.
• Regenerate the bundle on every push to main. This would create a commit for every merge and conflict with the policy of only committing the bundle in release PRs.

Additional context

Found while reviewing the release process after 1.5.2 (#80).