[Desktop] Governor eviction silently drops a session from cross-session messaging; on resume it re-registers under a different name and ref

### Environment
- Claude Desktop 2.110.0 (macOS), embedded Claude Code 2.1.271
- Several local Code-tab sessions open at the same time (memory-pressure evictions are routine on this machine)

### What happened
1. Session A (title set in the desktop sidebar since the morning) ran `ListAgents` at 22:37 local time. It reported: `This session is tmp-52 [41dcb0]`. So the peer name was an auto-generated one, not the desktop title.
2. Session A spawned several sessions with `spawn_task`. It expected to be reachable by them via `SendMessage`.
3. Main log, 11 minutes after A's last turn:
```
22:49:08 [CliGovernor] pressure evicting local_7bebc33c-… (idle 286s)
22:49:08 [CCD] Pausing session local_7bebc33c-… (governor_evict)
22:49:09 Session local_7bebc33c-… query iterator completed
```
4. For the next 9.5 hours A had no process, so it had no inbox socket. It was absent from every peer's `ListAgents`. The sidebar still showed it as an ordinary open session.
5. When the user typed in A the next morning, the app logged `Resuming session local_7bebc33c-…` and started a new process. `ListAgents` then reported `This session is [6915af]`. The name and the ref had both changed. The session ID, the transcript and the conversation were unchanged.

### Why it matters
- **`SendMessage` addresses the process, not the session.** A peer that saved A's name or ref, or was told it in a brief, cannot reach A once A is evicted. After A resumes, the saved name is also wrong. Nothing tells either side.
- **`notify_when_idle` in either direction dies with the evicted process.** The docs promise a 12-hour expiry notice for a subscription that never fires. When the subscriber itself is evicted, there is no process left to receive that notice.
- **The desktop channel handles the same case well.** `mcp__ccd_session_mgmt__send_message` with the `local_…` session ID wakes an evicted session and starts a turn. It queues the message when the target is busy. We verified both today. `get_session("self").parentSessionId` also gives a spawned session a stable pointer to its parent. The two messaging surfaces therefore behave very differently for the same target.
- **The peer name is inconsistent.** The first start used an auto-generated name, the resume used the desktop title.

### Expected
Pick one of these, in order of preference:
1. `SendMessage` to a paused (evicted) desktop session routes through the app and resumes it, as `ccd_session_mgmt.send_message` already does. `ListAgents` lists such sessions as `paused`, similar to how `offline` is shown for Remote Control sessions.
2. At minimum:
- A desktop session gets the same peer name on first start and on resume, preferably its sidebar title.
- The cross-session-messaging docs say that desktop sessions can be evicted and are then unreachable by name.
- The docs point to the session-ID channel as the durable option.

### Related
- #82663 (CliGovernor hard cap)
- #85160 (SendMessage: accept a session ID as address; closed as stale)
- #71773 (parent observes spawned children; closed as stale, now partly covered by `parentSessionId`)

Start with the SendMessage and ListAgents entry points and compare them with mcp__ccd_session_mgmt__send_message, using the reported eviction and resume sequence as the reproduction. Done should mean a stable peer identity and a documented or implemented paused-session delivery path; the issue names no repository files or tests.

Written by the indexing model from the issue text.