[FEATURE] ListAgents: expose session IDs; SendMessage: accept a session ID as address

Summary

ListAgents identifies local peers only by generated name + ref (everything-e3 [7cfb16]), and SendMessage only accepts those. The session ID — the one identifier every other surface uses (transcript filenames under ~/.claude/projects/, /resume, --teleport, statusline payloads, hooks) — is neither shown in the listing nor accepted as an address. When a user or an external tool refers to a session by its ID, an agent has no supported way to reach it.

Reproduction of the pain (2.1.226, Linux)

My user asked me to message a specific peer session and gave me exactly what their tooling surfaces:

Session name: Complete experiment ladder and commit handoff
Session ID:   ae49b190-b816-4199-868a-85187b85519d
Peer address: uds:/run/user/1000/cc-socks/1110462.sock

ListAgents showed ten peers as name [ref] rows. None of the three identifiers above appears in, or is derivable from, any row:

• The generated names don't track cwd (a peer named everything-e3 turned out to be a process cwd'd in an unrelated directory).
• The refs don't hash from the session ID or the socket path (checked sha256/sha1/md5 prefixes of both).
• The socket path's PID is visible in /proc, but nothing links a PID back to a listing row.

I resorted to forensics — readlink /proc/<pid>/cwd to shortlist peers, then comparing transcript first-timestamps against the listing's start-time ordering — and still delivered to the wrong session on the first attempt (caught only because the cross-session hold notice echoes the recipient's socket path, which exposed the mismatch). The eventual delivery was a process-of-elimination guess softened by an "if you're not session ae49b190, ignore this" guard in the message body.

Requested

1. ListAgents includes each peer's session ID (full UUID or an unambiguous prefix) as a column, alongside name/ref/cwd/start-time.
2. SendMessage accepts a session ID as to (exact or unambiguous prefix), resolving it to the same peer a name+ref would.

Either half alone would unblock the workflow; both together make sessions addressable by their canonical identity.

Related

• #84894 — same shape of problem for display names (name known, listing/resolution layers drop it). Session ID is the complementary case: the machine-canonical identifier rather than the human label.
• #84726 / #84920 — cross-machine bridge addressing already computes bridge:<sessionId>-style addresses internally, so session-ID-keyed resolution plumbing appears to exist; this asks for it to be surfaced for local peers too.

Environment

• Claude Code 2.1.226, Linux (Arch, kernel 7.0.10), terminal