host: adding or removing a human seat moves an unnamed group's name, and the guests already seated keep the old name #2009

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: 1e3838d8fd8f4738a5a30eeb3e6edaea
Branch: dev/1-human-seat-rename-broadcast
Base: b7fa18c
At: 2026-11-01T08:29:41Z

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

Written-by: FlyBot Lead

What happens

A human participant added to (or removed from) an unnamed group moves the host's room name — settleRoomName runs on both paths — but neither path tells the guests that are already seated. Guests keep the old name until some later room line happens to carry name.

core/src/host/room-membership.js on b7fa18c7:

• add — addRoomParticipant (:660) settles at :752, then only
  :754 if (record?.remote && record.handle) notifyRoomShare(... { op: 'join', handle })
:755 else if (record?.kind === 'bot' && !record.remote) reshareRoster(room).
  A human record (kind: 'human') is neither remote nor a Bot, so it hits no branch: 0 envelopes.
• remove — removeRoomParticipant (:760) settles at :803, then
  :810 else if (kind === 'bot' && !me.remote) reshareRoster(room) after the remote-leave and
  ticket-leave branches. A human removal is none of them: 0 envelopes.

This is reachable from the normal UI path, not a corner: group settings has an "add a member (person)"
entry (core/src/client/group-settings.js:258), and the stale name is what the guest sees in
core/src/shared/remote-label.js:219-224, client/details-drawer.js:213, client/group-settings.js:194.

Same defect class and same regression window as #2004 (#1999 made the host name move while guests
only hear about it per-seat). #2004/PR #2008 deliberately covers the remote-seat paths only; the two
human branches were left out and are tracked here.

Reproduction (real code, on b7fa18c7)

1. Unnamed group with one remote guest seated (Coder); no custom name.
2. Add a human (Bob) through the group-settings path.
3. Host name becomes Alice, Bob, Chief A, Chief B, Coder; the seated guest receives 0 join
   envelopes and its copy stays Alice, Chief A, Chief B, Coder.
4. Remove the human again: host name moves back, the guest receives 0 envelopes and stays stale.

Expected

The invariant #2004 established holds for human seats too: when a participant change moves an
unnamed group's name, the guests already seated receive one join carrying the new name — with the
participant that just changed excluded from that broadcast, so an arriving/leaving seat keeps its own
single targeted envelope. A chosen name, an inbound mirror and a face-to-face room still send nothing
for such a change.

Scope

• core/src/host/room-membership.js — the two human branches above (same shape as the five seat paths).
• core/test/remote-room.test.js — two cases: add a human to a room with a seated guest, remove one;
  red on base, green on the fix, and a control that a chosen-name room sends nothing.
• mirror patches/ds-bot/files/src/host/room-membership.js, docs/subsystems/core-host.md if the
  wording there lists the broadcasting paths, and a changelog.d/ entry.

Duplicate check (2026-11-01, before opening)

human participant rename broadcast → 0; reshareRoster human → 1 (#907, older roster listing);
group-settings add member stale name → 4 (#2004 open — remote seats only, #1771, #907, #1325).
No open or closed issue covers a human seat change failing to reach seated guests.