[BUG] Resumed teammates stay bound to the previous team after lead restart; SendMessage to team-lead reports success but messages are never delivered

Environment

• Claude Code 2.1.291, macOS (darwin 25.6.0)
• Lead session with named teammates spawned via the Agent tool (name set, in-process teammates)

Summary

After the lead session restarts, teammates resumed with SendMessage to their old agentId remain bound to the previous team. Their SendMessage(to: "team-lead") calls return success ("Message sent to team-lead's inbox"), but the message is written to the old team's inbox file, which the restarted lead no longer reads. The reports are silently lost. Nothing on either side signals a failure.

Steps to reproduce

1. In a lead session, spawn several teammates with the Agent tool using name. They are registered in ~/.claude*/teams/session-<A>/config.json.
2. Restart the lead session (in our case the session was resumed after a rate-limit pause; the transcript continued, but the runtime came back with a new session id).
3. The restarted lead gets a new team, teams/session-<B>/ (its config.json has leadSessionId = the new runtime id).
4. From the restarted lead, resume an old teammate: SendMessage({to: "<old agentId>", ...}). The tool result says it was resumed "as an in-process teammate with N prior messages".
5. The resumed teammate works and calls SendMessage({to: "team-lead", ...}). The result is success: true, "Message sent to team-lead's inbox".

Actual

• The message is appended to teams/session-<A>/inboxes/team-lead.json with read: false and is never delivered to the lead.
• In our session, 17 messages (substantive reports plus idle notifications) from 4 resumed teammates sat unread for ~2 hours. The lead stayed idle, believing it was waiting on them.
• A teammate spawned fresh after the restart joined session-<B> and its messages were delivered normally, so delivery is fine for current-team members and broken only for resumed ones.

Expected

One of:

• Resuming a teammate rebinds it to the lead's current team, so to: "team-lead" reaches the live lead; or
• SendMessage fails (not success: true) when the target inbox belongs to a team whose lead is no longer running; or
• The restarted lead also drains inboxes of earlier teams it led (same transcript).

Impact

Unattended multi-agent work stalls silently: the lead waits indefinitely for reports that were already sent. The only recovery is reading the stale inbox JSON by hand.

Related

• #76500 (lost final reports, turn-boundary delays): a different trigger, but the same symptom of a report that SendMessage says was sent never arriving.
• #71723 (name silently switches an agent to the teammate/mailbox path).