social: a room's own pending card is announced as "waiting for the owner's approval" #1638

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: ee92a97d4503404c83d5b08b45415548
Branch: dev/1638-social-a-room-s-own-pending-card-is-anno
Base: 331dd62
At: 2026-10-29T05:09:46Z

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

A room that holds its own pending approval card can still be told "Waiting for the owner's approval" while the dock's two polled lists are one beat behind — the very scene #1607 named ("the approvals list is a 5 s poll behind") but #1623 only half closed.

Written-by: FlyBot Lead

Reproduction (main 331dd620, after #1631)

plugins/social/client.js (ChatApprovalDock, ~:2385-2440) keeps two of its own polled lists (social/status + approvals, both re-fetched every 5 s), computes mine = approvalsForOpenChat(held, session), and:

const thisRoomHeld = held.some(item => item.roomId && roomIds.has(item.roomId))
const waitingOthers = mine.length === 0 && statusLoaded && listLoaded && !thisRoomHeld && (room?.pendingCount ?? 0) > 0

The room object handed to the dock already carries pendingApprovals (core/src/client/flybot-slots.js:166), and in core/src/host/channel.js pendingApprovals: pending; pendingCount: pending.length are the same array — so the room view can know the card is ours while the dock's own poll has not caught up.

Reproduced against the real client.js (__ModuleLoader__ harness), with room = { id: 'r1', origin: 'face-to-face', pendingCount: 1, face: { roomId: 'frm1' }, pendingApprovals: [ourHold] } and both endpoints answering empty for one poll:

• ZZ tree "[no-buttons]Waiting for the owner's approval" while ZZ roomHasOurCard 1 pendingCount 1

Second finding, same block

thisRoomHeld cannot be true when mine.length === 0: any held item whose roomId matches room.id/room.face.roomId is already collected into mine by approvalsForOpenChat (~:2119-2150), and the inline hold the comment names is filtered out at ~:2423 before that. So the guard protects nothing today; only the two load flags do.

Expected

While the room says it holds a pending card (pendingApprovals non-empty), the dock must not announce "Waiting for the owner's approval" — it draws either our card (once its list catches up) or nothing at all. It must never call our own card somebody else's.

Fix (scope)

Use the room's own array as the authority for "this room holds a card", e.g.

const roomHoldsCard = (room?.pendingApprovals ?? []).length > 0
const waitingOthers = mine.length === 0 && statusLoaded && listLoaded && !roomHoldsCard && (room?.pendingCount ?? 0) > 0

and drop or replace the dead thisRoomHeld guard (if you keep it, explain what it can still catch). Taking mine straight from room.pendingApprovals is allowed if it keeps the tests green, but it is not required.

Acceptance

• the probe's tree no longer draws the no-button "Waiting for the owner's approval" card while the room holds its own pending approval;
• a room with no pending card of our own still draws nothing (no new card in a quiet room);
• plugins/social/test/approval-dock.test.js stays green, plus one new case for the lagging-poll scene above;
• TZ=UTC ARCH_DOCS_BASE=<live main> npm run verify exits 0, ds-bot-patches check clean.