Push release target before publishing to avoid permanent tag-name reservation on Immutable Releases

[WillAbides]

Fixes #195.

Problem

On a repository with Immutable Releases enabled, PublishRelease (flipping draft = false) acquires a row in release_immutable_tags that permanently reserves the tag name on the repo (and across re-created repos with the same name). Per GitHub's docs:

If you delete the immutable release, you can delete the tag, but you cannot reuse the same tag name.

Runner.createRelease previously did:

1. tagRelease (push tag)
2. CreateRelease as draft + register DeleteRelease cleanup
3. uploadAssets
4. PublishRelease — this is when the immutable row gets created
5. pushTarget (push bake-commit branch to e.g. main)

When step 5 fails — typically because the runner can't bypass a branch ruleset — the deferred cleanupAfterErr deletes the published release, which orphans the row but never removes it. Every subsequent run that computes the same tag fails with GH013: Cannot create ref due to creations being restricted, and only GitHub Support can clear the row.

Fix

Two coordinated changes in release.go:

• Reorder. Move pushTarget to run between uploadAssets and PublishRelease. The release stays a draft (no immutable row) until the only plausibly-rejected step has succeeded. This matches GitHub's recommended Immutable Releases workflow: create draft → upload assets → publish.
• Cancellable cleanup. Change addErrCleanup to return a cancel func() and use it to cancel both the DeleteRelease cleanup (registered in createRelease) and the tag-delete cleanup (registered in run and passed down) immediately before PublishRelease. After publish has been attempted — success or failure — neither cleanup is safe: the server may have processed the publish even when the client saw a network error, and deleting either side in that ambiguous state orphans the row.

Behavior changes

Failure point	Before	After
pushTarget	Release deleted → orphaned immutable row, tag permanently reserved	Draft release + tag deleted cleanly. Retry works.
PublishRelease	Release deleted, tag deleted, target not pushed → clean retry	Release/tag/target left in place. User publishes the draft manually, or cleans up by hand.

The new PublishRelease-failure shape is a small regression for non-Immutable-Releases users, but it's necessary: the previous auto-cleanup is exactly what produces the catastrophic permanent reservation on Immutable Releases. Recovery is mild — one click on "Publish" in the GitHub UI.

--draft mode is unchanged (it doesn't push the target and doesn't publish; #195 doesn't apply to it).

Tests

Two new subtests of Test_releaseRunner_run:

• pushTarget failure cleans up draft release and tag — uses a pre-tag hook that writes the current branch ref to $RELEASE_TARGET and relies on the existing non-bare origin's default receive.denyCurrentBranch=refuse to reject the push. Asserts DeleteRelease is called (safe — still a draft), PublishRelease is not called (no mock expectation), and the tag was deleted from origin.
• PublishRelease failure does not delete release or tag — sets receive.denyCurrentBranch=ignore so pushTarget succeeds, then mocks PublishRelease to return an error. Asserts DeleteRelease is not called (the mock controller fails the test if it is) and the tag still exists on origin.

All existing tests pass unchanged.

Out of scope

• A pre-flight push permission check (the issue's option let's do v1 #2): requires either dry-pushing or reading rulesets and matching against the runner identity; adds API surface for marginal extra coverage on top of the reorder.
• Detect-and-warn on Immutable Releases (option validate_version #3): informational only; structural fix removes the need.
• Clearing existing orphaned rows (e.g. WillAbides/setup-go-faster v1.18.0-0): only GitHub Support can do that.