fix(release): stop a stale release cut from freezing an rc tag on an outdated commit

[joshua-temple]

Problem

An rc tag froze at a stale commit for a full day: a release cut recomputed an rc number that already existed and then silently failed to move the tag. Two compounding defects.

Defect 1 - version derivation had no collision guard. internal/orchestrate/orchestrator.go calculateVersion (and calculateComponentVersion) set the rc number from recorded state alone (state.Version fed to version.CalculateNext, which computes rc.N+1) and never consulted existing tags. When Finalize state-writes stalled behind a 409, the recorded version stuck at rc.0 and every cut recomputed the same rc.1, which already existed as a tag at an outdated commit.

Defect 2 - tag creation no-oped on an existing tag at a different commit. internal/release/release.go createGitTag treated a 422 reference already exists from POST /git/refs as unconditional success. That only holds when the existing tag already points at the target commit; when it points elsewhere the ref create is a silent no-op, so the tag stayed frozen on the stale commit while the cut reported success.

Fix

Defect 1 (advance): calculateVersion now resolves the candidate against the repository's tags. While a tag of the same name exists at a commit other than HEAD, the rc number advances until it is free. A tag already at HEAD is the same cut re-running and is reused unchanged; a candidate with no rc segment or an unresolvable HEAD is left untouched, so the no-collision path is byte-identical. Chosen semantics: advance rather than fail, because a stalled state resolving is a normal recoverable condition and the single-flight model wants the cut to make forward progress on the next free rc, not wedge.

Defect 2 (fail closed): on a 422, createGitTag now resolves the existing tag via GET /git/refs/tags/<name> and returns nil only when its target matches the requested commit; a mismatch (or an unresolvable target) fails loudly. Chosen semantics: fail loud, not force-move. An rc tag is immutable in the single-flight release model, so a fresh cut that needs a different commit takes a new rc number (Defect 1's job); no caller legitimately moves a tag, and there is no PATCH /git/refs force-update in the tree. This is the fail-closed safety net that turns the original silent freeze into a visible error. Same-sha 422 stays the genuinely idempotent success.

Verification

• Regression tests fail before / pass after both fixes (internal/release: existing tag at a different sha now errors instead of returning a silent nil; internal/orchestrate: a stuck-at-rc.0 state with an existing rc.1 tag at another commit now yields rc.2).
• go build ./..., go test ./... (3651 pass), go test -race on the affected packages, and golangci-lint run all clean.
• No generated-workflow drift: no CLI flag, manifest field, or generator surface changed; the full generator/schema suite passes unchanged.

[github-actions]

All PR Validation checks passed.