wire upgrade / session resume should cycle MCP servers (stale-identity root of #351)

[laulpogan]

Problem

A Claude session can end up displaying one wire identity (statusline) while operating as another (wire_* MCP tools) — the "two names" bug. Root cause: wire infers per-session identity, and the inference has no single stable source across the statusline, the long-lived MCP subprocess, and resumes.

The MCP server is a long-lived subprocess frozen to the session-key env it inherited at launch. On resume/reconnect the live session id drifts, but:

• wire upgrade swaps the sync daemons but not the MCP servers → they keep old code + old frozen identity.
• Claude Code doesn't re-key an MCP on resume.

So a stale MCP keeps answering as the wrong identity. Observed live: 19 stale wire mcp procs, one still carrying the long-since-guarded WIRE_SESSION_ID=${CLAUDE_CODE_SESSION_ID} literal env.

Now shipped (visibility half)

wire dash detects the split (session::detect_identity_split(): env-resolved key vs PID-file-resolved live key) and prints a ⚠ banner telling the user to /mcp reconnect. That makes it fixable in one command instead of a mystery.

This issue (the durable half)

Make the stale identity unable to outlive its session:

1. wire upgrade should restart/cycle the running wire mcp servers (not just daemons), so a post-upgrade MCP is never on old code / old identity.
2. Consider a session-resume signal so the MCP re-resolves its session key when the live id changes, rather than freezing at launch.
3. Reap orphaned wire mcp processes whose owning Claude session is gone (relates to the wire retire / wire dash --retire-idle sprawl cleanup).

Relates to #351. The dash split-detector landed on the observability-open-band branch (PR #360).