host: renaming a group never reaches the guests already seated in it #1949

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: 762e8d9ebe384f45b7e32687f68a9999
Branch: dev/2-p302-rename-push (reassigned to Dev-2 on 2026-10-31 after Dev-1's model quota was exhausted)
Base: 48c0df2
At: 2026-10-31T16:12:27Z

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

What happens

Renaming a group from the host never reaches the guests already seated in it. updateRoom (core/src/host/roster.js, main 48c0df28, lines 465-468) calls retitleRoom and nothing else; the membership push that tells seated guests about a settings change is one line below, and it fires only when the notice changed (:473, if (noticeChanged) void rt.notifyRoomShare?.(room, { op: 'join' })).

A guest applies a room name only from an envelope that carries name (core/src/host/room-membership.js:2491, room.name = cleanPeerName(data.name, room.name)), and only op:'join' / op:'line' envelopes carry it (notifyRoomShare, room-membership.js:1283; the join payload's name: room.name). Joins are sent on seat changes, notice changes and invitations — not on rename.

So a seat holder keeps showing the old name until the next line or any other push in that room. A quiet shared room keeps the old name indefinitely.

Reproduction

Two homes over the existing remote-room harness in core/test/remote-room.test.js (invite / publish / wire + addRoomParticipant('war', remote)):

1. a.rt.updateRoom('war', { name: 'War room' }, undefined, actorA) — guest reads 'War room' (green).
2. a.rt.updateRoom('war', { name: 'Renamed war' }, undefined, actorA) then settleShares() — the guest still reads 'War room' (red; expected 'Renamed war').
3. Only after postRoomMessage + fanoutRoomLine + settleShares() does the guest read 'Renamed war'.

So the boundary is precise: not permanent in a busy room, but the rename itself never travels.

Expected

A rename travels the same op:'join' push the notice change already uses — the envelope already carries name: room.name, so no new field is needed and the roster snapshot repeats no row it did not already repeat.

Scope

• core/src/host/roster.js updateRoom: one condition covering both settings — nameChanged || noticeChanged — and one push, not two, when both change in the same call.
• Must preserve the existing behaviour of #1939: writing the current name back (updateRoom('war', { name: 'War room', ... })) sends 0 envelopes. A test for that must stay green.
• One new case in core/test/remote-room.test.js; no new envelope field, no change to parseRoomShare / applyInboundRoomShare.
• Docs: docs/subsystems/core-host.md (the page that owns shared-room settings) if the rule needs a sentence; changelog fragment under changelog.d/.

Acceptance

1. After updateRoom(id, { name: 'Renamed war' }, ...) + settleShares(), the seated guest's room.name is 'Renamed war' with no further messages.
2. Renaming to the value the room already has sends 0 envelopes (#1939 unchanged).
3. A notice-only change still pushes (existing behaviour), and a call that changes both sends exactly one push.
4. The guest's roster, seats and history in that envelope are unchanged from the notice-push shape.

Duplicate check

Checked on live main 48c0df28: open issues — none. Closed — #1678 mentions retitleRoom only incidentally (busy ack), #1939 is the notice push (shipped), #1945 / #1946 are the notice/name text-bound and the cleared-notice-on-join family; a notifyRoomShare rename / rename room guest name search returns nothing. Backlog item P-292 covers the notice only, not the rename.

本账号无 AddLabelsToLabelable 权限：labels/assignee 未落，若评审侧按标签筛选请自行补
记账：Claim-Id 与 Branch 见正文头，claim 以正文头为准