[BUG] Agent Teams (in-process): team-lead "active agent" pointer sticks on a teammate after a long/compacted session — lead routes AS the teammate, Agent spawns fail "Teammates cannot spawn other teammates"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related but distinct: #31977 in-process teammates lack the Agent tool)
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

With Agent Teams (teammateMode: "in-process"), after a long-running team-lead session (many teammate spawn/shutdown cycles + at least one context compaction), the lead session silently loses its lead identity and starts operating AS one of the in-process teammates.

Concrete failure in my run:

• ~/.claude/teams/<team>/config.json still correctly had leadAgentId: "team-lead@<team>" and leadSessionId: <my session id>.
• BUT exactly one member entry — the most-recently-spawned in-process teammate (planner-...-rev2) — carried "isActive": true. No other member (not even the lead) had that flag.
• As a result, every action from my (lead) loop was attributed to that teammate:
• SendMessage from the lead went out with "sender": "planner-...-rev2" (the routing payload literally showed the teammate as sender, not team-lead).
• Every Agent (spawn a new named teammate) call failed with: Teammates cannot spawn other teammates — the team roster is flat. To spawn a subagent instead, omit the \name\ parameter.

So the lead can no longer dispatch new pipeline teammates, and its messages are mis-attributed — the team pipeline is effectively dead for the rest of the session, with no error explaining why (the spawn error misleadingly implies the caller is a teammate by design).

The trigger appears to be the in-process turn-scheduler leaving isActive: true on a teammate after that teammate yields, instead of resetting the active pointer back to the lead when control returns to the lead loop. Heavy spawn/shutdown churn + a context compaction seems to strand the flag.

What Should Happen?

When control returns to the team-lead loop, the "active agent" pointer should reset to the lead (the lead's actions must route as team-lead, and Agent spawns must work). The active-agent flag should never remain stuck on a yielded in-process teammate. If the lead identity is genuinely lost, surface an explicit error rather than silently demoting the lead to a teammate.

Error Messages/Logs

• Spawn: Teammates cannot spawn other teammates — the team roster is flat. To spawn a subagent instead, omit the \name\ parameter. (repeats every spawn attempt)
• SendMessage result routing showed "sender": "planner-...-rev2" instead of "sender": "team-lead".
• config.json: the single offending member entry had "isActive": true; leadSessionId still matched the running session.

Attempted workaround that did NOT recover the live session: editing ~/.claude/teams/<team>/config.json to delete the stuck "isActive": true had no effect on the running session — the active-agent state is held in memory, not (re)read from the file mid-session. Only a fresh claude session restores lead spawning. A file-based recovery (re-read config / a /team reset-active command) would help, since restarting loses all in-process teammates' in-RAM state.

Environment

• Windows 11, teammateMode: in-process, model claude-opus-4-8[1m], a single very long autoloop lead session with dozens of teammate spawn/shutdown cycles + one PostCompact.