ci: sync publish job to origin/main before computing version (eliminate stale-base release race)

[manaporkun]

Follow-up from PR #35 review.

Problem

The publish job's checkout pins to github.sha (the trigger commit), not the latest main. The test job takes ~5 min (Unity), and queued runs start even staler. So the version is computed against a stale base. When main advances during that window:

• Unrelated commits advanced main: PR ci: harden release flow against main advancing during a publish run #35's rebase-retry loop recovers (rebase auto-merges, push succeeds).
• A competing release bump advanced main: this run's bump and the upstream bump edit the same package.json version line + same CHANGELOG anchor -> rebase always conflicts -> loop fails fast (post-PR-ci: harden release flow against main advancing during a publish run #35) with a clear error, but the run still does no useful work.

Rebase-at-push treats the symptom. The root cause is the stale version computation.

Key fact

Main publish runs are strictly serialized by the concurrency group (group: workflow-ref, ref always refs/heads/main, cancel-in-progress=false). Only one runs at a time; others queue. So a run that syncs to origin/main at its own start sees whatever the prior run already published.

Proposed fix (Option C)

1. At the top of the publish job, before "Get current version", sync to the real latest main instead of building on the trigger SHA:

   git fetch origin main && git checkout main && git reset --hard origin/main

2. Compute version against fresh main. A redundant queued run then sees the already-bumped version -> bump=none -> skip=true -> all later steps gate off -> clean no-op, no conflict, no duplicate tag.
3. The window between sync and the final push shrinks to seconds (the expensive UPM-branch/tag work happens after the main push), so rejection becomes rare.
4. Keep PR ci: harden release flow against main advancing during a publish run #35's clean fail-fast loop as a thin backstop for that residual seconds-wide collision.

Why not just recompute inside the push loop

Recomputing only at push time relocates the failure to the tag step: the run would re-read the already-bumped version, find nothing to commit, no-op the push, then hit git push origin v<version> (non-force) where the tag already exists -> job fails at the tag step. The recompute must happen up front so skip is set correctly and every later step is gated off.

Acceptance

• Two back-to-back merges that each would bump -> exactly one release; the second run is a clean skip (green, no error).
• Unrelated advance during a release -> still lands cleanly.
• No git push origin <tag> collision; no half-finished rebase state.