host: a notice the host edits never reaches the guests already seated #1939

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: 62612f4261e3472791f340be5bcfd62a
Branch: dev/1-p292-notice-push
Base: 4d851e8
At: 2026-10-31T14:02:58Z

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

Written-by: FlyBot Lead

A host edits or clears the room notice and the guests already seated never see it: updateRoom only writes room.notice, and nothing in the host ever pushes a room-share envelope for that change. The envelope that carries the notice rides op: 'join', and a join is triggered only by a member entering or leaving (or by room creation), so a guest's copy keeps showing the old notice — possibly forever, until somebody happens to join.

Where it is wrong (live main 4d851e832084bdbf1fb8f8a2b1b78fce49bc4056)

• core/src/host/roster.js:438-441 — updateRoom writes room.notice and records a change, then saves and returns. No notifyRoomShare call.
• core/src/host/roster.js:350 — the only notifyRoomShare(...) call site in the file, inside room creation.
• core/src/host/room-membership.js:738 and :792 — the other join triggers: a member added or removed.

So the notice reaches a guest by accident of membership churn, never because the host changed it.

Expected behaviour

After a notice change on a room that already has guests, the host sends one room-share envelope with op: 'join' carrying the same roster snapshot as the previous envelope, with only the notice field changed — not a new row, and not one message per field. The guest's existing "present = replace, present empty = clear" handling then shows the new notice (or clears it). A patch that does not change the notice (or carries no notice at all) sends nothing.

Scope

• core/src/host/roster.js: hoist the existing notice guard into a boolean, and in the save()-then-return path call void rt.notifyRoomShare?.(room, { op: 'join' }) when — and only when — the notice actually changed. Same shape as the call at :350.
• patches/ds-bot/** regenerated by the normal generate flow; nothing hand-edited.
• One test in core/test/remote-room.test.js.
• Not in this change: the envelope budget, NOTICE_MAX / ROOM_SHARE_TEXT_MAX / ROSTER_MAX, the guest-side apply path, and the empty-notice-envelope defect that is tracked separately.

Acceptance (red first, both assertions independently red)

1. Two homes joined; host updateRoom(room.id, { notice: 'New' }) with members unchanged → exactly one op: 'join' send, parsed notice 'New', every other field of the envelope byte-identical to the previous one, room.log length and members unchanged; guest applyInboundRoomShare then yields room.notice === 'New'. Then { notice: '' } → exactly one more envelope whose parsed notice is present-and-empty, and the guest's notice becomes ''.
2. The same room, a patch that carries the old value ({ notice: '' } when there is no notice) or no notice at all ({ name, mode, admin }) → zero sends.

Duplicate check

Searched open and closed issues for notice push, notifyRoomShare, notice update, announcement on 2026-10-31: no issue covers "a notice change is never pushed". #1932/#1934 are the opposite face (a join drops the notice when the roster pushes the envelope, fixed and merged); #1933 was the unbounded cut; the empty-notice envelope case is tracked on its own. Grepped live main for notifyRoomShare: one call site in roster.js (:350), none in updateRoom.

Claimed-by: FlyBot Lead
Branch: dev/1-p292-notice-push
Base: 4d851e8
Dev: FlyBot Dev-1