Fix version-bump PR being silently discarded by create-pull-request action

[vchelaru]

Root cause

In the release_kind == 'release' path of .github/workflows/build-and-release.yml, the workflow used to:

1. Edit Gum/Properties/AssemblyInfo.cs to today's date ("Update AssemblyInfo.cs version" — unchanged by this PR, still runs unconditionally and its edit is correctly baked into the shipped binary by the build step that follows it).
2. In "Commit version bump, create tag, push branch+tag": check out a new branch version-bump/<tag>, commit the AssemblyInfo.cs edit directly onto it, create the annotated tag on that commit, then push both the branch and the tag.
3. In "Create pull request for version bump": call peter-evans/create-pull-request@v7 with branch: version-bump/<tag> — the same branch name step 2 had just pushed.

Because step 3's branch: input already existed on origin (pushed by step 2) with no further working-tree diff, peter-evans/create-pull-request@v7 treated it as an already-in-sync PR branch and force-reset it back to main's commit, discarding the version-bump commit. Confirmed in the logs of run 28795611132:

Branch 'version-bump/Release_July_06_2026' no longer differs from base branch 'main'

followed by a force-push and pull-request-operation = none.

The commit itself wasn't lost — the tag, pushed separately and earlier in step 2, still points at it — but no PR was ever created. This has been silently happening on every release since at least February: main's own Gum/Properties/AssemblyInfo.cs is still pinned at 2026.05.02, several releases stale, because there's never been a PR to review/merge the bump.

The fix

Swap the order: let peter-evans/create-pull-request@v7 do the committing itself (its normal, well-supported usage — discover the uncommitted AssemblyInfo.cs diff, commit it, push a fresh branch, open the PR), and create the git tag after, pointing at the commit SHA the action reports via its pull-request-head-sha output — instead of manually committing to the exact branch name handed to that action (which is what triggered its "already matches base" force-reset).

Replaced the two steps "Commit version bump, create tag, push branch+tag" and "Create pull request for version bump" with, in order:

• Create pull request for version bump (now id: version_bump_pr) — unchanged inputs otherwise, just moved earlier and given an id.
• Create and push release tag — tags steps.version_bump_pr.outputs.pull-request-head-sha and pushes that tag.

No other steps in the file were touched. "Compute tag + title" (produces steps.meta.outputs.tag/title, consumed by both) and "Capture previous release tag" stay where they are; "Create GitHub Release" stays last and is unaffected — by the time it runs the tag already exists, same as before.

Verification

This can't be exercised by unit tests or a local run — it's a workflow_dispatch-only workflow, no product code changed.

Done instead:

• YAML validated well-formed (parsed with js-yaml, all 16 steps in expected order).
• Confirmed pull-request-head-sha is a real output of peter-evans/create-pull-request@v7 (checked the action's action.yml directly) — this is the exact key already seen (as a genuine log excerpt, not a guess) in a prior real run.

Manual test: needed, but deferred to the next real release_kind: release run — the only way to confirm this end-to-end is to actually run "Build and Release Gum Tool" with release_kind: release and check that a PR titled "Bump version to Release_" appears (previously it silently didn't), and that the tag is created no differently than before.