Worktree auto-cleanup removes a worktree still used by a running nested background agent

A subagent launched with `isolation: "worktree"` starts a background child agent. The child inherits the same worktree (its meta shows `inheritedWorktreePath`, `spawnDepth: 2`). The parent then finishes without changes, Claude Code auto-removes the worktree (`worktreeCleanlyRemoved: true`), and ~6–8 s later every tool call in the still-running child fails with "working directory ... no longer exists ... Refusing to run there".

**Observed:** twice on 2026-09-14, Claude Code desktop app (2.1.220 (Claude Code)), macOS, main model Opus 5, subagents Sonnet 5 (`CLAUDE_CODE_SUBAGENT_MODEL`). Parent subagent_type `claude`.

**Timeline (one case):**
- 06:44:58 parent agent starts in `.claude/worktrees/agent-a59a…`
- 06:45:44 parent calls Agent (background); child inherits the worktree
- 06:45:50 parent ends with no changes → worktree removed
- 06:45:58 child stops: worktree no longer exists

**Expected:** don't auto-clean (or keep the git worktree lock) while a child agent inherited the worktree and is still running. Alternatively document this and provide a way to limit nested Agent spawning.

**Impact:** work lost, stage re-run from scratch (tens of millions of tokens).

Related but different: #41010, #76377.

Begin with the reported isolation: "worktree" parent-to-background-Agent child sequence and inspect the worktree auto-cleanup and inheritedWorktreePath lifecycle. Reproduce the timing where the parent exits before the child, then verify that the child’s tool calls continue to work and cleanup happens only after all users finish.

Written by the indexing model from the issue text.