Prototype administrative discussion mute controls

Let owners/operators mute or unmute new public/private sends from a human seat while retaining history, incoming messages, gameplay and credentials. Fence metadata and durable audit writes with live authority, membership and versions. Preserve exact admin/message retries and inherit restrictions through seat recovery.

Validation: types/lint, 5431 offline tests, build, 52 HTTP integration tests, 24 administrator HTTP groups, independent SQL/privacy/UI review and desktop/mobile refresh acceptance. All 2230 prior games and 4746 seats preserved. Additive migration 0016. Verified runtime fingerprint 588967fbb9c2e3b6abe2990c4fce96ee69e2256fb7e3ee416314b87593cebba9; documentation-only grammar/button-label review gives b5e57bdd26812debede91c588e38f247f1fa895ad23e7ae30bc8550eedcd90ec. New-revision deployed acceptance remains open; full admin/rules scope is unfinished.

docs/ADMIN_DISCUSSION.md

@@ -0,0 +1,67 @@
+# Administrative discussion controls
+
+**Discussion controls** in the administration directory lets an owner or operator
+mute or unmute new public and private messages from one human seat. Viewers can
+inspect the public roster and discussion settings. A muted player can still read
+history, receive messages and play the game. This prototype does not revoke seat
+access, remove a participant or permit administrators to read private messages.
+
+## Use and recovery
+
+Select the human participant, enter a short operational reason, type the room
+code and acknowledge that the setting follows the seat. **Mute discussion** or
+**Unmute discussion** applies the change. Human seats using AI remain eligible;
+permanent AI seats do not send messages. Closed and archived rooms permit settings
+for reopening; a removed room must first be restored. Closing a room still blocks
+all new sends independently of its seat settings.
+
+The player sees a persistent explanation when muted, with **Refresh discussion
+availability** for checking an unmute while browsing older history. Only the
+caller's mute status is returned with their message page. Other players receive
+no mute indicator or private discussion activity. Incoming history remains under
+the existing sender/recipient privacy rules. Recovery and voluntary handover
+inherit the logical seat's setting; revoked credentials remain invalid.
+
+The exact admin operation, room version, seat-setting revision, target, setting
+and reason are saved in account/room-scoped tab storage before sending. The first
+request shows concise progress. Uncertain requests retain explicit retry controls
+across refresh; success text stays until a deliberate action. Retrying an old
+mute after a later unmute confirms the old receipt without muting again. Existing
+committed message requests can likewise be confirmed while muted; altered or
+new requests cannot bypass the restriction. A new owner cannot replay the former
+credential's message receipt.
+
+## Persistence and authority
+
+Additive migration [0016](../drizzle/0016_seat_discussion_controls.sql) stores
+seat settings separately from game JSON. The action leaves room versions, game
+change timestamps, private custody, credentials, readiness and AI pacing intact.
+It requires the current room version and a separate seat-setting revision. Live
+admin authority, human membership, room availability and both versions are fenced
+at commit. The setting and audit receipt commit together or roll back together.
+Message insertion independently checks the live mute setting in SQL, preventing
+a stale browser from sending. A message committed before a later mute still
+returns its successful receipt.
+
+Controls: [admin panel](../components/admin-discussion.tsx),
+[player discussion](../components/table-talk.tsx),
+[client retry](../lib/admin-discussion-client.ts).
+Server: [route](../app/api/admin/rooms/[code]/discussion/route.ts),
+[admin transaction](../db/admin-discussion.ts), [message store](../db/table-talk.ts).
+
+```sh
+npm test -- admin-discussion table-talk
+npm run test:integration -- admin-boundary table-talk
+```
+
+Focused regressions cover rollback, concurrent/conflicting operations, live
+role/session/membership/version changes, stale revisions after unmute, receipt
+replay, own-only status, incoming messages, mute/send ordering and seat rotation.
+The dedicated admin HTTP verifier creates a new QA room for deny/mute/read/retry/
+unmute flows and preserves both seats. Independent SQL/privacy and UI source
+reviews found no blocking defects. Browser, checkpoint and preservation evidence
+are recorded separately; deployed acceptance must match the running revision.
+
+Access revocation, disruptive participant removal, administrator-assisted recovery,
+backup/restore and operational audit browsing remain unfinished. Discussion
+moderation is a partial participant-support prototype, not full admin acceptance.