Background Agent subagent's worktree/Bash sandbox gets redirected by parent session's later EnterWorktree call

## Impact observed

- A background subagent's ~150 lines of uncommitted work (a schema/validator addition) were briefly destroyed when the parent, believing a directory had accumulated unrelated stray files, ran `git checkout -- ` against what turned out to be the subagent's real in-progress work — because the subagent's writes had landed in the parent's currently-pinned worktree rather than its own. Recovered without permanent loss only because the subagent still had the content in its own context and could restate it verbatim.
- A second, differently-shaped incident the same day (possibly the same root cause, possibly a distinct issue — see below): a different background subagent, told to create its own worktree, encountered a benign/transient git message (`failed to store: 100001` / `could not lock config file` — a credential-helper artifact that in our experience never corresponds to a real git failure) while attempting `git worktree add`, and — rather than retrying — concluded it should work in "its already-assigned worktree," which turned out to be the parent session's own home worktree. This may be the same underlying mechanism surfacing differently, or an unrelated model-behavior issue (treating a benign warning as a hard failure). We were not able to cleanly separate the two explanations.

## Model tiers observed

- The **confirmed, deliberately-reproduced** instance (the numbered repro above) was on **Opus**.
- The second, differently-shaped incident was on **Sonnet** — but as noted above, we can't be certain it's the identical bug rather than a related-but-distinct failure mode.
- A third incident was reported by a peer Claude Code session on the same machine, same day, writing to the same repo — it found its own uncommitted content (an appendix to a planning doc) sitting in a worktree belonging to an already-merged branch, written via an absolute-path `Edit` tool call rather than a relative Bash path. That session flagged it as a possibly more serious variant, since an absolute-path edit landing in the wrong place would rule out ordinary relative-path/cwd confusion, but explicitly hedged that it couldn't rule out its own user/harness error either. We were unable to confirm that session's model tier before it completed its own task and its worktree was cleaned up.

## What we'd expect instead

Either:
- A background subagent's sandbox/worktree assignment is fixed at dispatch time and never affected by anything the parent session does afterward, or
- If a shared/global "current worktree" concept is intentional, a subagent should be told explicitly (not just refused with a generic message) that its assignment changed out from under it, so it can stop and report rather than silently working somewhere unintended.

## Workaround we've adopted