Let the merge sync lose a push race instead of failing

[darksidemilk]

Closes FOGProject/fogproject#1219

sync-generated-files.yml in fogproject is disabled right now because this step keeps
failing. It is a push race, not a permissions problem — worth saying, because the previous two
failures on this path were permissions and that is where the eye goes.

What happens

The job checks out a branch, then spends ~50s on checkout, apt-get, the php-cs-fixer download,
translation regen and PSR2 formatting before it pushes. Any PR merged into that branch during the
window moves the remote:

! [rejected]  HEAD -> working-1.6 (fetch first)

Measured on the run that took the stub down:

Time	Event
14:11:43	actions/checkout of working-1.6
14:12:05	an unrelated PR is merged into working-1.6
14:12:32	git push → rejected

3 of the last 15 runs died this way, each within ~60s of another run.

Not a race between two sync runs. The stub's concurrency group already serialises those. This
is the job racing a human pressing Merge, which no concurrency setting reaches — and cross-repo
concurrency does not exist anyway, since groups are per-repository.

Why fail soft rather than rebase and retry

FOG_VERSION is derived from commit count since master. The instant the remote gains a commit,
the version computed a few steps earlier is stale — a rebase would push a number that is already
wrong. Skipping keeps correctness because the next merge sync or the daily cron recomputes from
scratch, and it cannot feed itself, which matters more here than anywhere else in this repo given
the 30-commits-in-20-minutes incident a self-triggering sync once caused.

Same trade the stub already documents for fork PRs: better a gap the schedule already covers than
a red X.

The check is specific, not blanket. HEAD~1 is the commit the job checked out, since the commit it
makes is the only one. If origin/<branch> is no longer that, the branch moved and skipping is
right; if it still is, the push failed for another reason and the job still fails.

The second edit is not optional

Summarize keys its version line on steps.version.outcome — the "Apply version fix" step,
which succeeds whether or not anything reached the remote. So a skipped push would still have
printed "🔧 Version fixed — old → new" for a version that was never pushed, while the
steps.commit.outcome check below stayed quiet because the step now exits 0.

Fixing only the push would have traded a red X for a false report. The raced branch is emitted
before the version line so it wins, and steps.commit.outcome now covers only genuine failures.

Verification

The race is impractical to wait for, so it was reproduced with real git — three scenarios against
a real bare remote:

GH-1219 push logic
  ok    raced: exit status (0)
  ok    raced: emits ::warning:: (yes)
  ok    raced: sets raced=true output (yes)
  ok    raced: remote untouched
  ok    genuine failure: non-zero exit (yes)
  ok    genuine failure: does NOT set raced (unset)
  ok    clean push: exit status (0)
  ok    clean push: remote advanced

8 passed, 0 failed

After merge

Re-enabling fogproject's workflow is a repository setting, not a diff, so it does not arrive with
this PR:

gh workflow enable 336670600 --repo FOGProject/fogproject

🤖 Generated with Claude Code

https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK