Desktop/web session rename doesn't propagate to cross-session registry (ListAgents/SendMessage still show derived name)

Summary

Renaming a session in the desktop/web app (via the toolbar title or /rename) updates the sidebar label, but never gets written back to the session registry file (~/.claude/sessions/<pid>.json) that ListAgents/SendMessage (cross-session messaging) actually reads. As a result, a renamed desktop session still appears to other sessions under its auto-derived fallback name (e.g. office-23), even though its own sidebar shows the real name.

CLI sessions don't have this problem — claude --resume <name> / --name <name> sets the registry name correctly at launch.

Environment

• Affected sessions: entrypoint: "claude-desktop" (desktop/web app)
• Unaffected: entrypoint: "cli"
• claude-desktop version observed: 2.1.229
• CLI version observed: 2.1.232
• OS: Linux (WSL2)

Steps to reproduce

1. Start a session in the desktop app in a project directory (e.g. ~/Code/Office).
2. Note the auto-generated name it gets, e.g. office-23 — visible via another session's ListAgents call, or by reading ~/.claude/sessions/<pid>.json, which shows "name":"office-23","nameSource":"derived".
3. Rename the session in the GUI — either by clicking the session title in the toolbar, or via /rename <newname> typed in the chat.
4. Confirm the sidebar now shows the new name.
5. From a different session, run ListAgents, or cat ~/.claude/sessions/<pid>.json for the renamed session's PID.

Expected

The renamed session shows its new name in ListAgents output from other sessions, and the registry JSON reflects the rename (e.g. "name":"<newname>", with nameSource no longer "derived" or replaced by a nameSince timestamp, matching what a CLI-launched session's file looks like after --resume <name>).

Actual

ListAgents from other sessions still shows the old auto-derived name (office-23, etc.), and the registry file still shows "nameSource":"derived" with the original derived name — the rename never propagates past the local UI.

Evidence

Comparing a CLI session's registry file (name correctly set) against a desktop session's (rename didn't take), captured in the same environment at the same time:

// CLI session (entrypoint: "cli") — name set correctly
{"pid":221468,...,"entrypoint":"cli","name":"Chief","nameSince":1786724195894,...}

// Desktop session (entrypoint: "claude-desktop") — renamed via toolbar + /rename in the GUI,
// sidebar shows the new name, but this file still shows the untouched derived name:
{"pid":227681,...,"entrypoint":"claude-desktop","name":"office-dd","nameSource":"derived"}

This was reproduced across four separate desktop sessions in the same sitting — all four kept "nameSource":"derived" in their registry file after being renamed via both the toolbar and /rename, while the one CLI session in the same set had its name set correctly.

Impact

This breaks cross-session addressing for any multi-agent workflow that mixes desktop/web sessions with CLI sessions (or relies on desktop sessions being addressable by name at all) — peers can't reliably SendMessage a desktop session by its intended name, since ListAgents never reflects the rename.