resume a restart-killed agent in its own worktree instead of redoing the work

[atomantic]

Summary

An agent killed by a server restart never reaches its completion hook, so nothing recorded what it left behind. Its task was requeued to a fresh agent that built a new worktree off the default branch and redid work that was still sitting on disk — including everything the dead run had not committed yet, which is most of it when the kill lands mid-edit.

The retry now picks up where the interrupted run stopped:

• resolveTaskResumePatch is the one answer to "can this be resumed?", used by every path that retires a dead run — the boot/health-check orphan sweep, resetOrphanedTasks, the post-restart completion recovery, and the normal failure path. It returns a set patch (resume this), a clear patch (the pointer is spent — the branch merged or vanished), or an empty patch (nothing to say). Previously only the normal failure path recorded anything at all, which is why the restart case — the one that can't reach that path — was the one that redid its work.
• handleOrphanedTask folds the patch into the same write that flips the task to pending. That flip emits tasks:changed, which can spawn the retry immediately, so a pointer written afterwards could land too late to be read.
• adoptWorktree moves the dead run's worktree to the retry's own directory via git worktree move, carrying its commits, uncommitted edits, and untracked files intact. The move (rather than adopting in place) preserves <worktrees>/<agentId> == "the agent that owns this tree", which is the invariant cleanupOrphanedWorktrees reaps on — left at the dead agent's path, the live retry's worktree would be reaped out from under it. When the tree is gone but the branch survived, the retry attaches to the branch instead; when neither is usable it starts clean.
• The prompt tells the retry what it's holding — that it is continuing someone else's run, and to read git status, the commit log, and whether a PR was already opened or merged before writing any code.

Work that already landed is still never resumed onto. A branch reads as merged for two opposite reasons, and the change separates them: commits that shipped (ahead > 0 — refuse, the agent-d2ae0352 shape) versus a branch that never committed at all (ahead == 0 — nothing to duplicate, so a dirty tree on top of it is safe to adopt). That second case is precisely the restart shape, and treating it as "merged" is what would have thrown the work away.

Test plan

• cd server && npm test — 53 suites fail on this machine both before and after this branch, all requires PostgreSQL (no test DB provisioned here); no agent/worktree/task suite is among them.
• New coverage: worktree adoption and its refusals (worktreeManager.test.js), the landed-work guard, lockfile-only dirt, repurposed directory, the early bail before the branch comparison, patch set/clear/leave-alone (cleanupAgentWorktree.test.js), the orphan sweep's ordering and its single combined write (agentManagement.test.js), prep's adopt → attach → clean fallback chain (agentWorkspacePrep.test.js), and pointer survival through an orphan cooldown (cosTaskStore.test.js).
• git worktree move verified by hand against a scratch repo: modified tracked files, untracked files, and the branch all survive the move.
• Reviewed by codex[gpt-5.6-terra] (3 rounds, every finding fixed) and ollama[Qwythos-9B] (clean). Codex found three real gaps this branch introduced or left open: a resume was unreachable for runs isolated by conflict auto-detection rather than an explicit flag; the completion path never wrote the clear patch, so a task kept pointing at a since-merged branch; and the terminal-status cleanup stripped the pointer on an orphan-cooldown block, which auto-revives to pending and so silently abandoned the work. Ollama's one finding (git.getBranch missing) was a false positive — but the suites mock git.js wholesale and structurally could not have told us, so this adds a guard asserting the real module against the real caller.