[BUG] 2026-08-24 build breaks desktop-to-desktop Remote Control: resumed sessions never re-publish, /remote-control spawns duplicates, list regrouped into machine folders

Summary

Desktop to desktop Remote Control worked cleanly on 2.1.234. After the 2026-08-24 auto update (CLI 2.1.237 and 2.1.241, desktop shell 1.34493.1, macOS 15 / Darwin 25.5.0 on both machines), session publishing and the session list broke in five connected ways. Data is intact locally; everything below is sync and presentation.

Setup

• iMac runs all sessions in the desktop app with "remoteControlAtStartup": true in ~/.claude/settings.json. It is the only publisher.
• MacBook runs the desktop app as a viewer. "Enable Remote Control for all sessions" is off there.
• Both machines on current versions (verified same day).
• On Friday 2026-08-21, on 2.1.234, every iMac session appeared in a flat list on the MacBook and stayed in sync. No folders, no archived rendering, no duplicates.

What broke after the update

1. Resumed sessions never re-publish. After the desktop app restarts, existing sessions (including pinned ones) do not re-arm Remote Control. Opening or clicking the session on the publishing machine does nothing. remoteControlAtStartup is honored for brand new sessions only.

1. /remote-control in an existing session creates duplicates instead of reattaching. Running the command in a previously published session registered a new server side session each attempt. One client session ("CrossBreeze") now shows many copies in the viewer's list. Related: #83917 warns that archiving one of several same named sessions can kill a live one, so the duplicates cannot even be cleaned up safely.

1. Published sessions are now grouped into machine and user folders ("tyler", the machine name, repo derived folders such as the git root name) instead of the flat list 2.1.234 showed. No setting controls this. Same class of regression as #79156.

1. Idle sessions render as archived on the viewing device after roughly 10 minutes, while the publishing machine still shows them active. Tapping reattaches. Same behavior as #32651 (closed as not planned) but the archived rendering is far more aggressive on this build, and archive state remains per client (#65838).

1. Transcript holes after reattach. Anything exchanged while the link was down is permanently missing from the viewer's transcript after reconnect. Same as #34531. The local .jsonl on the publishing machine is complete.

Repro

1. Two Macs, both on the 2026-08-24 build, one account.
2. On machine A set remoteControlAtStartup: true, create sessions, confirm they appear on machine B.
3. Quit and reopen the app on machine A. Resume the sessions. They never reappear on machine B.
4. Type /remote-control in one resumed session. A duplicate registration appears in machine B's list each time.
5. Let any published session idle 10 minutes. Machine B renders it archived.
6. Reattach after a dropped link. The outage window is missing from machine B's transcript.

Expected

What 2.1.234 did on Friday: resumed sessions re-publish, /remote-control reattaches to the existing registration, flat session list, idle sessions stay visible, transcripts backfill on reconnect.

Refs

#32651, #65838, #34531, #83917, #79156, #67811