fix(release): break the stuck-tag deadlock in the nightly release guard

[matthewevans]

A tag whose Release run died before the publish gate (v0.21.0: Build Server
(windows) hit the old 35-minute timeout and was cancelled) deadlocked the
nightly permanently. Two independent defects compounded:

1. Signal mismatch. The version step derives next_minor from the highest
   PUBLISHED GitHub Release, but the existing-tag guard keyed off release-RUN
   conclusions. When those disagree the nightly jams: version computation keeps
   recomputing 0.21.0 (no published release), the tag already exists, and the
   guard hard-exits on the stale cancelled run. Nothing in the nightly could
   ever clear that. Key the guard off the published release instead -- the same
   fact the version step already uses -- so the two cannot disagree, and a tag
   with no published release self-heals into a recovery dispatch.

2. Recovery could never carry a fix. dispatch-recovery ran
   gh workflow run release.yml --ref "$TAG", which EXECUTES the release.yml
   frozen in the tag's tree -- i.e. the same broken workflow that just failed
   (35m timeout). A CI fix landed on main could not reach a stuck tag. Dispatch
   from main instead; -f tag= still pins the built SOURCE to the tag SHA via
   resolve-release-ref, so this changes CI config only, never released code.

Dropping the guard's "already in progress" branch (it matched runs by
head_sha == TAG_SHA, which a main-ref dispatch no longer satisfies) means a
tag-push and a recovery dispatch could in principle overlap, so release.yml
gains a per-tag concurrency group. cancel-in-progress is false: a half-cancelled
release is precisely what leaves a tag stuck.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.