Cross-session messaging: peer names/sockets silently invalidate on session resume; no stable addressing or self-identification

Environment

• Claude Code desktop app (claude-code 2.1.237), macOS (Darwin 25.5.0)
• Multiple interactive sessions on the same machine coordinating via cross-session messaging (ListAgents / SendMessage)

Problem

Cross-session peer addresses resolve to UNIX sockets at /tmp/cc-socks/<PID>.sock. Every session resume or app restart changes the PID, which silently invalidates:

1. the peer's displayed name (e.g. myproject-54 → -ab → -10 → -34 for the same logical session within one day), and
2. every from= reply address previously handed to peers.

Peers replying to a stale name/address get No agent named 'X' is reachable. In a leader/worker workflow this caused repeated delivery failures: workers could not report back after the leader session was resumed, and one worker attempted to reply to a role name ("lead") three times before a human noticed.

What we had to build as a workaround

• Keep a ledger file with the app-level session ids (local_<uuid>, undocumented) and route reports via the desktop app's tab-delivery (send_message by session id), because those ids survive restarts.
• A session cannot query its own id, so each new leader must ask a peer to look up the leader's id via list_sessions.

Requests

1. A stable, restart-surviving address for cross-session SendMessage (or automatic re-binding of the old name to the new socket).
2. An official way for a session to query its own session id / address.
3. Alias or role-name resolution (or at least a clearer error that distinguishes "unknown name" from "name expired after restart").
4. A reply path for app-level tab-delivered messages (they currently arrive without any from= address).
5. A resume-time re-announcement path: a way for a session to tell known peers, or a registered channel, that it has come back and what its current address is. A session-resume hook event carrying that address would be enough. Stable addressing alone does not cover this, because peers still have no way to learn that a peer restarted. (Raised by @kcarriedo below.)

Related: #84945 (socket bind failure making messaging one-way).