fix(social): one lagging poll after face-start still closes the face room #1612

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: eefba1a9339e49f6a6ca752549041daa
Branch: dev4/fix/face-start-miss
Base: 655aa71
At: 2026-10-29T00:26:23Z

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

Written-by: FlyBot Lead

Problem

#1606 fixed "a face room flips to closed 1–3s after face-start when the member list has not caught up" by requiring two peerless snapshots instead of one. The counting is still fed by every snapshot source, and face-start itself is one of them, so the start response already spends the one snapshot of slack: one lagging poll after start closes the room and sends face-leave, which is the original symptom.

Live main 655aa714609b34836d4b021072f6a3cbe593f0dd, plugins/social/src/social.js:

• :4041-4059 facePeersGone(snapshot, hosted, locals) — const misses = here.size > 0 ? 0 : (prev ?? 0) + (known.size > 0 ? 1 : 0); known is seeded from hosted.participants (the peers face-start seats locally), so a snapshot that lists no members still adds 1 here.
• :4065 applyFaceSnapshot(snapshot, { asBot }) calls it for every snapshot, and four write paths reach it: pollOneFace :4243, joinFaceRoom :4360, setFaceLead :4236, startFaceRoom :4443-4446 (the faceNeed().start() result goes straight in).
• faceSnapshotPast :4023 closes the room once peerGone is true.

So the sequence "start (member list lags) → open the room / next poll (still lags)" is: miss 1 at start, miss 2 at the poll → closed. The comment at :4056-4059 describes "two snapshots", not "two polls", but #1606's own Expected is that a transient empty member list must not end the room; a single poll after start is exactly that transient window.

Reproduction

1. A peer home joins the room first: flybot/social/face-join with the code, so hosted.participants holds @…:remote:true.
2. Simulate the lag #1606 recorded: the server's room member list is empty (room.members = []) while the peer is still seated here.
3. flybot/social/face-start on that room.
4. One flybot/social/face-rooms poll.

Observed: the room reads closed and a REST POST /<room>/leave is sent. Expected: still open — one poll is not proof the peer left.

Driving the same scenario through face-start in the existing suite is enough to see it; the #1606 regression test cannot, because it sets room.status='open' / room.started_at by hand (plugins/social/test/social.test.js:2617-2635) instead of calling face-start, so no start snapshot ever spends a miss.

Scope (S)

1. Advance / clear the per-room miss counter only for poll snapshots: e.g. applyFaceSnapshot(snapshot, { asBot, poll }) → facePeersGone(..., { count: poll }), with pollOneFace passing poll: true and the start / join / lead paths not counting (either skipping the increment or resetting the room's counter to 0).
2. Keep faceSnapshotPast's immediate close on a snapshot carrying member.left — a real leave must still end the room on the first snapshot.
3. Replace/дополнить the #1606 test so it drives the real face-start endpoint and then a single lagging poll, and keeps a two-poll case proving a genuine peer leave still closes the room.

Out of scope: UI copy, leaveFaceRoom's call conditions, the Past-room ended-reason enhancement, and anything in #1605.

Acceptance

• After face-start with a lagging member list, one poll leaves the room open and sends no face-leave; a second poll that still lists no peer closes it as today.
• A snapshot with member.left closes the room immediately (existing behaviour kept).
• New test fails on 655aa714 and passes with the fix; plugins/social suite green; npm run verify exit 0 at the PR tip.

Branch

dev4/fix/face-start-miss