fix: regenerate Gemfile.lock on the release PR after version bumps

[fuzzyrichie]

Summary

PR #319 (release-please's own generated release PR) is failing CI:

The gemspecs for path gems changed, but the lockfile can't be updated because
frozen mode is set

Root cause: release-please's ruby release strategy only bumps lib/apollo-federation/version.rb (our configured version-file) and CHANGELOG.md — it has no Bundler awareness, so it never touches Gemfile.lock. That leaves the checked-in lockfile still pinning the old version for this repo's own self-referencing path gemspec (gemspec path: '..' in the Gemfile), which is a hard error under the frozen mode ruby/setup-ruby@v1 enforces in CI.

This never surfaced under the old semantic-release flow because that job explicitly unfroze Bundler (bundle config set --local frozen false) and committed a regenerated Gemfile.lock atomically alongside the version bump in the same direct-push commit — e.g. ea4df19 (chore(release): 3.10.3) touched CHANGELOG.md + Gemfile.lock + version.rb together, and the diff was a single line (just the pinned version). release-please has no equivalent hook for this.

(Earlier revision of this PR tried removing Gemfile.lock from version control entirely — reverted, since that let other transitive dependencies (json) resolve to newer versions incompatible with the pinned graphql ~> 2.0.0 in the main Gemfile, breaking tests that were passing under the frozen lockfile. Keeping the lockfile and fixing it properly is the safer path.)

Fix: added steps to the release-please job that, whenever release-please-action creates/updates a release PR, check out that PR's branch, unfreeze Bundler, run bundle lock, and commit+push the result back onto the PR — directly replicating what the old semantic-release job did.

Verified locally with the same Bundler version ruby/setup-ruby would install (2.6.6, read from Gemfile.lock's BUNDLED WITH): bumping version.rb and running bundle lock unfrozen only touches the one apollo-federation (X.Y.Z) line, matching every historical release commit's diff exactly.

Test plan

• Verified locally that bundle lock (unfrozen, matching Bundler version) only updates the one pinned-version line
• CI green on this PR
• After merge, confirm the next push-to-main run regenerates and commits Gemfile.lock onto chore(main): release 3.10.4 #319 (or its successor), and that PR's CI goes green

[sethc2]

SHIP IT