[Bug] iTerm2 native split-pane disabled by in-process fallback in auto mode

Bug Description

iTerm2 native split-pane teammates never activate due to isInProcessEnabled() short-circuiting backend detection.

ITermBackend is fully implemented and detectAndGetBackend() correctly detects iTerm2 + it2 CLI and would select it. But this code path is never reached.

The teammate spawn logic calls isInProcessEnabled() first, and if it returns true, it runs teammates in-process without ever calling detectAndGetBackend(). Here's the problem in isInProcessEnabled():

function isInProcessEnabled() {
  if (isNonInteractive()) return true;
  let mode = getTeammateModeFromSnapshot();
  if (mode === "in-process") return true;
  if (mode === "tmux") return false;
  else return !insideTmux(); // "auto" mode
}

When teammateMode is "auto" (the default), the else branch runs !insideTmux(). In iTerm2 without tmux, this returns true, so teammates always run in-process. There's no iTerm2 check here — it treats "auto" as a binary tmux-or-in-process decision.

Meanwhile, detectAndGetBackend() has the correct logic:

if (inITerm2) {
  if (it2Available) return new ITermBackend(); // would work, never reached
}

Two issues

1. "auto" mode ignores iTerm2

isInProcessEnabled() should be aware of iTerm2:

// Current (broken):
else return !insideTmux();

// Fixed:
else return !insideTmux() && !isInITerm2();

Or better: have the "auto" path delegate to detectAndGetBackend() to check if any pane backend is available before falling back to in-process.

2. teammateMode: "iterm2" not handled

"iterm2" isn't a recognized case in isInProcessEnabled() — it falls through to the else branch and behaves the same as "auto". It should be handled like "tmux":

if (mode === "iterm2") return false;

Environment

• Platform: macOS (darwin)
• Terminal: iTerm2
• Claude Code: v2.1.39 through v2.1.42
• it2 CLI: v0.2.0 installed and working
• tmux: not installed

Related issues

• #23815
• #24301
• #24292