fix: recover published rebased gate lanes

[AgardnerAU]

Summary

• Add no-mistakes axi sync --adopt-published to recover a stale gate lane after a clean branch is rebased and force-with-lease pushed.
• Make structured custody-returned/diverged status direct the operator to that recovery instead of to axi run, which cannot make the rejected non-fast-forward push.
• Cover the successful rebased case, rejection of an unpublished divergence, and sibling-lane isolation.

Reproduction

Before this change, recover custody, rebase the branch onto newer main, add a commit, and publish it with a lease-protected force update. The gate lane still names the pre-rebase head, so its ordinary branch push rejects as non-fast-forward and the pipeline cannot start.

Design

Recovery is explicit, rather than an automatic reset during axi run. The command only operates on the current lane after it verifies that custody was returned, the worktree is clean, the preserved lane still matches the recovered pipeline head, and the configured push target exactly matches the local rebased head. It imports that verified remote object, rechecks the remote and local assumptions, preserves the old gate head, then moves only the lane with a compare-and-swap update. Any failed guard leaves the lane unchanged. This rejects local or remote divergence that has not been safely published.

Verification

• make lint
• go test -race ./...
• go build -o ./bin/no-mistakes ./cmd/no-mistakes

[greptile-apps]

Confidence Score: 4/5

The target-resolution mismatch should be fixed before merging because it can reject valid recovery or verify publication against the wrong remote.

Adoption does not reliably query the same authoritative push target used by the pipeline when the current worktree origin differs from the refreshed repository registration.

Files Needing Attention: internal/branchsync/sync.go

_{Reviews (1): Last reviewed commit: "fix: recover published rebased gate lane..." | Re-trigger Greptile}

[greptile-apps]

When the worktree origin differs from the refreshed upstream registration used by the pipeline, the database-loaded repository has URLsVerified unset, so resolvedPushURL queries origin instead of the pipeline's configured destination. This rejects a legitimately published rebased head as blocked_published_head_mismatch, or accepts adoption based on publication to the wrong remote.

Context Used: If there is a VISION.md file at the root of the re... (source)

[kunchenguid]

Speaking as Kun's firstmate:

Reviewed the tip (054f4bad) and Greptile's P1.

Diff read (fail-closed): --adopt-published is explicit opt-in recovery: custody-returned + diverged only, clean worktree, gate lane must still match the preserved head, live configured push target must exactly equal local HEAD, import via temp ref, recheck assumptions, preserve old gate head, then CAS the lane. Unpublished divergence refuses. Sibling lanes stay untouched. Docs/skill/guidance updated. Tests cover success, unpublished refuse, and flag conflicts. That shape aligns with Never lose work / loud refuse.

Greptile P1 (blocking for merge): resolvedPushURL prefers worktree origin whenever !URLsVerified, even if that origin is not the registered upstream. Adoption can then verify (or reject) against the wrong remote. Please fix so publication is always checked against the same authoritative push target the pipeline uses (credential-preserving origin only when redacted equality holds, or an equivalent verified binding) — then re-request review.

CI: First-time fork workflows approved on this head (CI / docs / Guard / Require no-mistakes). Waiting on green + the P1 fix. Greptile Review is currently red on that P1.

VISION.md (this PR tip):

• One gate, one meaning: aligns — recovery is explicit; does not dilute core pipeline.
• Never lose work: aligns if P1 is fixed; cannot tell while target resolution can bind the wrong remote.
• Judgment stays human: aligns — opt-in command; no silent auto judgment.
• Independent validation: aligns — does not change reviewer/fixer separation.
• Evidence over confidence: aligns — structured adopt_published next_action + refuse codes.
• Humans and agents: aligns — same flag in axi/human CLI and skill.
• Scope: aligns — corrective recovery for a real stranded published-rebase case; opt-in, not always-on service growth.

Classification: corrective / opt-in recovery (not a default-behavior gate-meaning change). Not merging while P1 is open / CI unsettled.