ci: release push fails non-fast-forward when a second PR merges during the first release

[TMHSDigital]

What

Two PRs merged in quick succession make the first release run fail. Observed on 2026-09-23:

1. fix(examples): resolve --output against the working directory in three render paths #223 merged as 2321b2a, and release run 35846619099 started, checked out 2321b2a.
2. fix(gallery): regenerate the 25 drifted heroes from their code, with contact sheets #225 merged as c010da5 before that run reached its bump push.
3. Run 35846619099 committed chore: bump version to 0.79.13 [skip ci] on top of 2321b2a, then:

   ! [rejected]        main -> main (non-fast-forward)
   error: failed to push some refs
   ##[error]Process completed with exit code 1.
   

4. The queued run for c010da5 (35846626973, concurrency: release) then scanned both commits since v0.79.12 and released v0.79.13 covering both. Pages deployed from the resulting bump commit 026b568.

Net effect: no lost release and nothing half-published. The failure happens before tagging, so no tag was pushed without its commit. But main shows a red Release run, and the fix: push's own Pages deploy was skipped by the #219 gate while its release never dispatched one. The next release covered it.

Why

release.yml checks out the triggering SHA, bumps, then git push origin main (around line 157). The concurrency group serializes the runs, but a run that has already checked out cannot see a merge that lands during it.

Options

• Before the bump commit, git fetch origin main && git rebase origin/main (or git pull --rebase). If the rebase brings in commits, the version decision should be recomputed over the new range, or the run should exit cleanly and leave the release to the newer run, which will scan the whole range anyway.
• Simplest: if origin/main has moved past the checked-out SHA, exit 0 with a notice. The queued run for the newer SHA releases everything since the last tag, as happened here.

release.yml pulls fleet-owned pieces (release-doc-sync, meta-repo-ref: v1.15.1), so the fix may belong upstream in the fleet template rather than here.

Workaround until then: merge the next PR only after the previous PR's Release run has finished.