axi run cannot recover when gate branch ref exists but no pipeline run was recorded

Summary

no-mistakes axi run can get stranded when the local no-mistakes gate repo already has a branch ref, but the daemon has no recorded pipeline run for that branch.

In that state:

• git push no-mistakes HEAD returns Everything up-to-date
• the bare repo post-receive hook does not fire
• no pipeline run is created
• no-mistakes axi run --intent ... keeps failing with:

no run started for "<branch>": no previous run for branch <branch>

The branch is then stuck until the local gate ref is manually deleted and recreated.

Reproduced

Seen independently on at least two branches:

• fm/demo-factory-verify-a1
• codex/add-sqlite-axi-catalog

What happened

1. Branch ref already existed in the local no-mistakes bare gate repo.
2. No pipeline run existed for that branch.
3. Running git push no-mistakes HEAD was a no-op because the ref already pointed at the same commit.
4. Because the push was a no-op, the post-receive hook did not fire.
5. Because the hook did not fire, no run was created.
6. no-mistakes axi run --intent ... could not start or recover the missing run.

Safe workaround

Delete and recreate only the local no-mistakes gate ref:

git push no-mistakes :refs/heads/<branch>
git push no-mistakes HEAD:refs/heads/<branch>

Then run:

no-mistakes axi run --intent "<intent>" --yes

Important: this does not delete or force-push the GitHub branch. It only refreshes the local no-mistakes gate ref so the bare repo hook fires and creates the missing run.

Expected behavior

axi run should recover from this state instead of staying stranded.

Possible fixes:

• If the gate ref exists but no run exists, axi run should create/reconstruct a run from the current gate ref.
• Or the push/hook path should treat same-SHA pushes as meaningful when no run exists.
• Or the error should print the exact safe repair command above.

Actual behavior

The user gets a dead-end error:

no run started for "<branch>": no previous run for branch <branch>

That message does not explain that the gate ref exists without a recorded run, and it does not tell the user the safe recovery command.