ListAgents shows stale session name after /rename until the renamed session runs a turn

Environment

• Claude Code v2.1.226 (also reproduced on v2.1.225-era sessions)
• macOS (Darwin 25.6.0), CLI + desktop app
• Cross-session messaging (ListAgents / SendMessage, available since v2.1.224)

Describe the bug

When a session is renamed mid-session with /rename, other sessions' ListAgents peer rows keep showing its old name (often the auto-generated slug like repo-dir-4e). The new name only appears after the renamed session next runs a turn (processes any message or user input). Meanwhile, the from-name attribute on delivered cross-session messages does resolve to the new title — so the two views disagree.

Steps to reproduce

1. Start session A in some repo directory. It registers under an auto slug name (e.g. myrepo-4e).
2. In session A, run /rename my-task-name, then leave A idle (no further turns).
3. In another session B on the same machine, run ListAgents → A's row still shows myrepo-4e. SendMessage with to: "my-task-name" fails to resolve ("not an agent in this conversation").
4. From B, send A any message addressed by its stale slug name. A processes it (runs one turn). Its reply arrives with from-name="my-task-name" — the new name.
5. Run ListAgents in B again → A's row now shows my-task-name (same [ref]).

Expected behavior

/rename should propagate to peer-visible discovery immediately, or ListAgents should resolve current session titles at query time (message delivery's from-name resolution already does).

Actual behavior

The registry name is only refreshed lazily on the renamed session's next activity. An idle renamed session is unreachable under its new name, even though it is alive and listed.

Impact

A common workflow — rename a window for its next task, then message it from another session by that new name — fails with "not in reachable list". It is confusing to debug because the session is alive, is listed (under the stale name), and replies do show the new name.

Related

#31394 (closed as not planned) is about the /resume list display; this report is specifically about cross-session peer discovery (ListAgents), which that issue does not cover.