isolation: worktree forks new agent trees relative to the primary checkout's live state, not the calling session's own tree

Title: isolation: worktree forks new agent trees relative to the primary checkout's live state, not the calling session's own tree

Body:

When a session running inside a linked git worktree (not the primary checkout) dispatches subagents with isolation: worktree, the new agent trees are created relative to the primary checkout's current HEAD/state — not the calling session's own branch or working directory. If any other actor (the primary session itself, another worktree, a routine commit) mutates the primary concurrently, the newly spawned trees can silently fork from a stale or unrelated commit.

Concrete repro/evidence:

• Calling session was working in a linked worktree (e.g. ~/project-worktrees/feature-x), on its own branch, well ahead of the primary checkout's current state.
• Dispatched 5 concurrent agents with isolation: worktree.
• 3 of 5 spawned trees forked from a commit 826+ commits behind the intended target — confirmed via git merge-base --is-ancestor and git worktree list, not assumed.
• The primary checkout's reflog showed a commit landing in the exact same time window (an unrelated session doing routine work there), consistent with the new trees having forked from whatever the primary's HEAD happened to be at that instant.
• This is a second occurrence of the same underlying behavior; the first (weeks earlier) also involved isolation: worktree moving/racing the primary's HEAD.

Why this is surprising: a user/session working inside a linked worktree reasonably expects fan-out spawned from that session to be scoped to that session's own tree/branch state, not silently coupled to an unrelated checkout elsewhere on disk that they may not even be actively using.

Suggested fix direction: a new isolation: worktree tree should fork from the calling session's own current working directory/ref (or at minimum, this coupling to the primary checkout should be explicitly documented so it's not a silent surprise).

Current workaround (ours, not asking Anthropic to build this): we added a mandatory self-verify-and-fast-forward step as the first action of every such spawned agent, which reconciles a stale-but-unmodified fork cleanly and refuses to proceed on a genuinely diverged one. It mitigates the symptom but doesn't address the root cause.