host: a seat change renames the room on the host, and the guests already seated keep the old name #2004

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: f9941587bf0040868436d4a637892f98
Branch: dev/2-seat-rename-broadcast
Base: a989587
At: 2026-11-01T07:17:33Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What happens

#1999 made an unnamed group's title follow its seats on the host: settleRoomName (core/src/host/room-membership.js:425-431, called at :752, :803, :1790, :1995, :2273) rewrites room.name and retitles the Session. It sends no envelope. Every remote seat path notifies only the seat that changed (:754 join, :784 leave, ticket tellSeats :1856, all filtered by handle inside notifyRoomShare :1301); only a local Bot add/remove (reshareRoster, :1041) and a member rename (followMemberNames) broadcast. So a guest that is already seated keeps its copy of the room name until the next room line carries name.

Visible in the ticket/link room sidebar (core/src/shared/remote-label.js:219-224 renders room.name) and in client/details-drawer.js:213, client/group-settings.js:194, client/palette.js:62, client/schedules.js:218. A friend's shared room pins the sidebar to Shared room from <inviter>, but the drawer and settings header show the stale name.

It is a regression introduced by #1999, not older debt: before it, the host's room.name did not move either, so both sides agreed on the old name. Now the host moves and the guest does not.

Reproduction (on live main a989587f, probe against a real remote home)

1. Seat a first guest (Coder) in an unnamed group — host and guest both read Alice, Chief A, Chief B, Coder.
2. Seat a second guest (Writer) in the same room.
3. Host's name becomes Alice, Chief A, Chief B, Coder, Writer; the copies held by Coder and by Writer still read Alice, Chief A, Chief B, Coder — zero envelopes were sent.
4. Remove Coder: host name is Alice, Chief A, Chief B, Writer, Writer's copy still carries Coder.
5. Seat Coder again: still stale for both.

Assertion that fails: expected 'Alice, Chief A, Writer A, Chief Beta, Coder, Writer' / actual 'Alice, Chief A, Writer A, Chief Beta, Coder'.

Local member rename/removal/re-add and "an unnamed group gains a seat then loses it" are both correct today; the gap is remote seats and the guests already in the room.

Expected

After any seat change that moves room.name, every already-seated remote guest gets one new copy of the name — the same text the host holds — so the two never disagree for the lifetime of the room, not just until the next message. A guest that arrives after the change already gets the new name (:754 targeted join); the guests already there must not be the ones left behind.

Scope

• core/src/host/room-membership.js: settleRoomName reports whether the name moved; remote add/remove, ingestSeatShare leave, evictUnshared and the ticket claim path then trigger one broadcast through the existing reshareRoster (:1041, a no-op with no remote seats). Keep the targeted join where it already happens — do not send two joins for the same arrival.
• core/test/remote-room.test.js: one case in the shape "a second guest sits / leaves / comes back → a guest already seated receives a join whose name is byte-identical to the host's room.name". Red first on a989587f.
• patches/ds-bot/files/src/host/room-membership.js and patches/ds-bot/0002-flybot-api-host.patch mirrors, regenerated by generate (this takes the generate slot — see dependencies).
• changelog.d/… fragment and the docs/subsystems/core-host.md seat/name row if its sentence stops being true.

Non-goals

• #1999's own guards (skip when the name did not move, inbound-share, isFaceRoom) stay as they are.
• No new envelope op, no client change: the envelope already carries name.
• Not the room-lock work (settleRoomName awaits retitleRoom inside withRoomLock); that is tracked separately.

Dependencies

patches/ds-bot/0001/0002 regeneration is serial with the PRs currently in flight, so this one starts as READY-only (branch + red-first proof + verify) and opens its PR when the slot frees.

Duplicate check

Live main a989587f: settleRoomName exists only in this file and its two mirrors; open issues searching settleRoomName, "guest stale room name", "seat name guest notify", "retitleRoom" → 0 open, the neighbouring ones are closed and different faces (#1995/#1999 seat/formula, #1968/#1970 automatic rename from member rename or removal, #1949/#1952 settings rename). No open issue covers a guest already seated keeping the old name after a seat change.