Worktrees from `isolation: "worktree"` auto-reap when subagent returns without changes, breaking SendMessage resume

Summary

Subagents spawned via the Agent tool with isolation: "worktree" have their worktrees auto-cleaned up if the agent returns without making file changes. This breaks the SendMessage resume flow when the subagent's first turn is a clarifying-question checkpoint (reads files, stops to ask the parent agent for decisions before writing).

Reproduction

1. Parent spawns subagent with Agent({ ..., isolation: "worktree", name: "my-agent" }). Subagent is instructed to "ask clarifying questions before writing code."
2. Subagent runs: pwd + git worktree list confirms isolated worktree. Reads files. Returns a question-list as its result without making any commits or edits.
3. Harness reaps the worktree per documented behavior: "the worktree is automatically cleaned up if the agent makes no changes."
4. Parent agent processes the questions and calls SendMessage({to: "my-agent", message: "<answers>"}) to resume.
5. Subagent resumes but its worktree is now gone. pwd resolves to the primary working directory. Per preflight rules, the subagent stops rather than risking contamination.

Impact

The ask-first subagent pattern — where subagents surface unknowns to the parent before committing to an implementation path — is fundamentally broken under isolation: "worktree". Parents are forced into one of:

• Over-specify prompts (pre-answering questions they don't know the answer to — defeats the point of delegation)
• Instruct subagents to make throwaway "scaffold" commits before asking (band-aid; adds noise to PR history)
• Skip worktree isolation (risks contention with parent agent's working tree)

None are clean. The ask-first checkpoint is a core pattern of the delegation model.

Proposed fix (any of)

1. Worktrees from Agent calls with name set (i.e. resumable via SendMessage) should not auto-reap on first return. Cleanup deferred to session end.
2. Add explicit keepAlive: boolean option to the Agent tool. When true, the harness persists the worktree until the parent explicitly indicates no further SendMessage calls.
3. SendMessage automatically re-provisions the worktree from the subagent's preserved branch state before resuming.

Observed in

• Anthropic Claude Code CLI, session on 2026-04-19
• Pattern reproduced twice in one session with two separate subagents. Both were respawned with over-specified prompts to avoid the ask-first path; recovery worked but at the cost of re-reading files and re-accruing context.

Current workaround (documented in our /elephant command)

Kickoff prompts instruct subagents to make an empty scaffold commit before asking clarifying questions:

git commit --allow-empty -m "scaffold: branch placeholder"

Worktree kept alive, but adds a spurious commit to rebase out before PR. Smells like a workaround to future session readers.