[BUG] Agent Teams: teammate-emitted shutdown_request registers against the team lead; the routing error message then steers the lead into approving its own termination

## Environment

- Claude Code CLI 2.1.220, Linux (Ubuntu, kernel 6.8), Agent Teams via the native Agent tool (tmux teammates)
- Hit twice in two days in two different sessions/projects on the same machine

## Summary

When a teammate emits a `shutdown_request` itself (intending to request its OWN shutdown), the harness registers the request with an id suffixed `@team-lead` -- i.e. targeting the lead session. The lead cannot route the `shutdown_response` to the teammate: SendMessage rejects it with

```
shutdown_response must be sent to "team-lead"
```

If the lead complies with that error message and sends `{"type":"shutdown_response","request_id":"shutdown-@team-lead","approve":true}` to `"team-lead"`, the LEAD session terminates itself mid-work: the main process exits, MCP servers drop, background monitors die, and every spawned teammate dies with the lead's socket.

The documented semantics ("Approving shutdown terminates your process") are technically honored, but the combination is a footgun: the teammate believes it is requesting its own shutdown, the lead believes it is approving the teammate's shutdown, and the error message actively directs the lead to the self-terminating call.

## Repro

1. Lead spawns a teammate via the Agent tool (named teammate, tmux backend).
2. Teammate finishes its work and, instead of asking in prose, emits `SendMessage({to: "team-lead", message: {type: "shutdown_request", ...}})`.
3. Lead receives a message stating a shutdown_request is pending with id `shutdown-@team-lead`.
4. Lead sends `shutdown_response` (approve: true, echoing the id) to the teammate's name -> hard error: `shutdown_response must be sent to "team-lead"`.
5. Lead re-sends the same response to `"team-lead"` -> the lead session exits immediately.

Observed exactly this sequence on 2026-07-26; a second session hit the same class the previous night. The working direction (lead ORIGINATES `shutdown_request` -> teammate approves -> teammate exits, `shutdown_approved` comes back) behaves correctly.

## Expected

Any of:
- A teammate-originated `shutdown_request` addressed to the lead is treated as a request to shut the TEAMMATE down (that is always the intent in a lead/worker topology), or is rejected at send time with guidance ("ask the lead to originate the request").
- The lead's `shutdown_response` on such a request routes to (and terminates) the requesting teammate, not the lead.
- At minimum: approving a request whose target is your own session produces a confirmation-style warning naming the consequence, instead of an error message that instructs the exact self-terminating call.

## Actual

Lead session terminates itself; all teammates and background state die with it. No warning that the approval targets the approver's own process.

## Related

#77076 looks like a sibling failure in the same protocol area (unsolicited `shutdown_approved` frame exits the lead). This report is the `shutdown_request`/`shutdown_response` direction of it, with the added twist that the harness's own routing error steers the lead into the fatal call.

Reproduce the Agent tool sequence with a named tmux teammate: have it send a shutdown_request through SendMessage, then follow the shutdown_response routing error. Trace the shutdown_request, shutdown_response, and shutdown_approved handling and how request IDs are suffixed with @team-lead. Done means the request targets the teammate or is rejected with guidance, and approving a self-targeted request warns about termination.

Written by the indexing model from the issue text.