Run stranded after a late-step failure post-rebase: gate ref left at the old sha, and every recovery command refuses or no-ops

Summary

When a run fails at a late step after the pipeline has already rebased the worker's commit, the gate repository's branch ref is left at the pre-rebase sha, while the worker's clean local head is the rebased one. The two diverge (the old sha is not an ancestor of the new one). From that point, every supported recovery command either refuses or reports success without changing anything, so the branch is stranded.

Observed on no-mistakes v1.72.0 (9fcc865). The daemon was healthy throughout.

What each command does in that state

• no-mistakes axi run is rejected as a non-fast-forward push.
• rerun refuses because the selected head differs from the clean local head.
• sync --check reports custody returned and next action run_pipeline, as if nothing were wrong.
• sync --recover --keep-local is accepted and exits successfully, but it is a no-op: the gate ref stays at the old sha. Its help text says it recovers custody while keeping the local head.
• bind-archive-ref only binds evidence; it never moves a ref.
• abort has nothing to abort, because the run is already terminal.

Steps to reproduce (shape)

1. Start a run on a branch whose base has moved, so the pipeline rebases the commit before its later steps.
2. Let the run fail at a step after the rebase (in our case the CI step could never pass, and the auto-fix round was aborted).
3. Try to start a fresh run on the same branch with the clean, rebased local head.

Expected

A supported way to re-select the gate head after a rebase, or sync --recover --keep-local actually moving the gate ref to the clean local head, as its help describes.

Workaround in use

Push the same validated commit under a new branch name, which is a clean create. It works, but it leaves a dead ref in the gate repository each time, and every future stranded run needs a rename.