[Bug] Agent dispatch with isolation:"worktree" causes cwd state bleed into parent session

Bug Description
Report:

Bug: Agent dispatch with isolation:"worktree" bleeds
  worktree-session state into the dispatching parent session

  Running a Conductor-style pattern (dispatch several concurrent
  implementer agents in one batch via the Agent tool, each
  independently creating its own git worktree under
  .claude/worktrees/) repeatedly caused the dispatching parent
  session's own cwd — which never called EnterWorktree itself — to get
  hijacked into one of the dispatched agents' worktrees. Happened 4+
  times across one long session.

  Symptoms:
  1. An unprompted "Primary working directory" environment-update
     retargets the parent session's cwd to
     .claude/worktrees/<dispatched-agent's-worktree>.
  2. Once hijacked, the harness actively refuses any git command
     referencing the original primary checkout — both cd <primary> &&
     git ... and git -C <primary> ... get hard-refused with "This
     session is isolated in the worktree ... Refusing to run it."
  3. A plain cd to a directory outside the repo entirely gets silently
     reverted after the command completes (tool output shows success,
     then "Shell cwd was reset to <worktree path>").
  4. Recurs repeatedly across a session (not a one-time glitch) —
     happened at least 4 separate times over ~2 hours of dispatching
     agents.
  5. Confirmed to affect dispatched agents too, not just the
     dispatching parent — a sibling agent independently reported its
     own session's cwd bouncing between two other agents' worktrees
     mid-task, with no action on its part.
  6. Side effect: dispatched agents' worktrees sometimes end up
     created nested inside another agent's worktree directory rather
     than both at the top level of .claude/worktrees/ — no data
     corruption (each remains a distinct git worktree/branch), just
     wrong placement.

  Reliable recovery: ExitWorktree(action:"keep") successfully returns
  a hijacked session to its correct directory every time — even though
  the tool's own docs say it should be a no-op "if called outside an
  EnterWorktree session." Either it's more permissive than documented,
  or something is genuinely registering these hijacks as an
  EnterWorktree-equivalent state that isn't otherwise visible.

  Impact: blocks local git-based operations (post-merge sync, local
  file inspection) for the affected session until noticed and
  recovered. No data loss/corruption observed — API-based operations
  (e.g., a Gitea REST/MCP merge) are unaffected since they don't
  depend on local git state. But it's a real, repeat-hitting
  disruption to a routine, frequent pattern (dispatch several
  concurrent worktree-isolated agents), not an edge case.

  Context: macOS, Claude Code CLI, lowescloud/server repo, a
  board-auto-develop-style Conductor session dispatching 4-5
  concurrent Agent(isolation:"worktree") calls per wave.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.267
• Feedback ID: effcf799-32d1-4b8a-b726-f4b3bb9b442e

Errors

[]