[HugoXK]

End the old server's face rooms when the server changes
Fixes #729
Switching the Bot Social server disposes the old social layer but leaves the face-to-face rooms it hosted in core state with face.status: 'open'. The new layer has none of them in its settings.faceRooms, so nothing polls them, and its faceApi belongs to the new server: a line typed into such a room was appended locally while the fanout failed (face_room_not_found / no speaker identity), which room-membership.js only warns about. The room still showed an open composer, so every line the person typed was silently lost.
When the switch succeeds, server-config.js now marks the previous server's open/candidate face-to-face rooms left (a read-only past room; switching back re-polls them on that server and they reopen). channel.js also refuses send and room-post for a face room whose status is left or closed (bot/room-ended) and appends nothing, so a stale client cannot write a line no home can receive. A failed switch never reaches this step.
plugins/social/test/social.test.js hosts a face room on server A, switches to B and asserts it is left (fails without the change: it stays open). core/test/room-membership.test.js sends to a left face room and asserts bot/room-ended with the room log unchanged (fails without the change: the line is appended). docs/subsystems/social.md and docs/subsystems/core-host.md record both.
Ran at the tip: npm run verify (green, TZ=UTC), ARCH_DOCS_BASE=upstream/main node core/scripts/check-arch-docs.mjs, ds-bot-patches generate + check. Not run: smoke (this macOS box has no setsid, so dev/bench.sh cannot start dsh web), Desktop, real-model steward.

[Birfy]

Verdict: INC at ca22e15
Written-by: Reviewer

Two items. The core of the change is right — both ends are refused, the switch marks the old server's rooms left, and the switch test does pin that — and every check is green at this tip. Neither item is a redesign.

1. The room-post guard is not pinned. channel.js gains the same refusal on two paths, room-post (the browser posting into a room) and send (the Session path). The new test only covers send: I deleted the two room-post lines (const posted = rt.roomOf(…) and its fail('This room has ended', 'bot/room-ended')) and core/test/room-membership.test.js was still 14/14. So the UI path can silently go back to appending a line into a room no home can reach.

   This test passes at this tip as written and fails with the guard removed (posted.ok === true), so it can be added as is:

   test('channel: room-post into an ended face room is refused too', async (t) => {
     const { call, rt } = startChannel(t, TEAM)
     await rt.load()
     const room = await rt.upsertFaceRoom({ roomId: 'frm_left', localId: 'g-left', status: 'left', name: 'Ended room' })
     const before = room.log.length
     const posted = await call('room-post', { roomId: 'g-left', text: 'hello' })
     assert.equal(posted.ok, false)
     assert.equal(posted.error?.code, 'bot/room-ended')
     assert.equal(rt.roomOf('g-left').log.length, before, 'nothing was appended')
   })

2. "switching back re-polls them on that server and they reopen" is not true. That sentence is in docs/subsystems/social.md and again as the comment over endFaceRooms in plugins/social/src/server-config.js, but social.js faceSnapshotPast holds the state it was left in: if (held === 'left' || held === 'closed') return { status: held }, with its own comment "Once the room is left or closed here, a later poll must not reopen it (Face-to-face: avatars and room title differ per home (regressions of #137/#172); Leave is abrupt and not seen by the peer #182)". applyFaceSnapshot passes that through as the status, so after A → B → A the room still reads left here and the new guards refuse every line typed into it: it is a past room for good, not "reopened". Nothing tests the round trip, so nothing tells the reader which of the two is intended.

   Pick one and make it true: either (a) drop the claim and say in social.md that switching is one-way for the old server's face rooms (you start a new room when you come back), or (b) actually reopen a room when its own server is selected again — the room already carries face.roomId and there is a place to clear the hold — and assert it in social.test.js by switching away and back, checking the status returns to open and a typed line is accepted. Either way, the comment and the doc must match the code.

Ran:

• cd plugins/social && TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test --test-name-pattern="Settings server" test/social.test.js → 4/4 pass at this tip
• red, as the PR body claims: await endFaceRooms(previousFaceRooms) commented out in server-config.js → 3 pass / 1 fail, Settings server: status, check and switch …
• cd core && TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/room-membership.test.js → 14/14 pass at this tip
• red, the gap in item 1: the two room-post guard lines deleted → 14/14 still pass; with the test in item 1 added → 15/15 with the guard and 14/15 (the new case) without it

Not run: the full core suite and the full social suite (I ran the two files this PR touches and the switch cases); node scripts/ds-bot-patches.mjs check — it needs git, which this box does not have, so the generated patches/ds-bot/… files are covered only by CI's green tests-ok/package at this tip; no browser check (no client file changed).

[Birfy]

Written-by: Dev

Superseded by #776, which carries this change from ca22e157 (with Co-authored-by: HugoXK) plus both items from the INC at ca22e157:

• the room-post guard now has its own case in core/test/room-membership.test.js — remove the guard and it goes 14/15, the new case red;
• the "switching back re-polls them and they reopen" claim is gone from docs/subsystems/social.md and from the comment over endFaceRooms, and the switch test asserts the round trip: back on the old server the room is still left and a line posted into it is refused (bot/room-ended).

Why a new pull request rather than a new tip here: this branch lives in HugoXK/FlyBot and we cannot push to it (permissions.push: false; blob creation answers 404). maintainer_can_modify is on, but the API has no path for another owner's account to commit into that fork, so the fixes cannot land on this branch.