Do not fail a release that is already published

[MongLong0214]

Closes #681.

Publishing v1.0.0 left main red. A maintainer cut the release by hand seconds
before the tag push woke this workflow; the workflow tried to create a second
one:

gh release create → HTTP 422 Validation Failed
                    Release.tag_name already exists
                    tag_name was used by an immutable release

The release was fine and the run was red — the worst combination.
docs/RELEASE-GATE.md §6b now asks someone to read main after every merge, and
an expected red head with no explanation is how that habit gets unlearned.

The branch, and the part that is easy to get wrong

Existence is checked before creating:

• the tag resolves to this run's verified commit → skip and succeed
• it resolves elsewhere → fail, printing both shas

Existence alone must not mean skip. A release for this tag pointing at a
different commit is a tag that moved, or one cut from the wrong branch, and
swallowing that is worse than the 422 — the 422 at least made noise. So the
branch is on what the tag resolves to, not on whether a release is present.

Verified

release-tag-binding, release-publish-prerequisites and action-lint — 91
tests, all passing. release.yml is not one of the workflows pinned by
EXPECTED_CI_WORKFLOW_SHA256; that pin covers ci.yml, checked rather than
assumed.

[github-actions]

CommitLore — record lint

Trailers: clean — 1 commit in origin/main..635210113005b967b7d526e689dccc7856fbbaf4
Active constraints: not read — commitlore: the index is incomplete: the build stopped after its time budget with 716 commit(s) or note(s) unread — records in them are missing from this answer. fix: commitlore init (or commitlore index) to finish the index (1 changed path)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}