Verify anonymous production support intake

docs/public-launch-checklist.md

@@ -216,15 +216,18 @@ as forward-only rather than receiving an invented database rollback.
 - [x] The Activity flow passes: create, request to join, approve/decline,
       withdraw, rejoin, group chat, exact-location disclosure only after
       approval, and reporting.
-- [ ] Support, privacy/data, account-deletion, general content-removal, and
+- [x] Support, privacy/data, account-deletion, general content-removal, and
       TAKE IT DOWN submissions reach the correct production operator queues.
       A 2026-08-21 run-scoped check proved authenticated support, privacy,
       data-export and account-deletion submissions plus separate general
       content-removal and TAKE IT DOWN records. Staff found every record in its
       permission-scoped production queue, and exact cleanup left zero records
-      with the run prefix. Anonymous contact verification still requires a
+      with the run prefix. A separate 2026-08-25 production mail smoke proved
-      controlled production mail smoke before this combined item can be
+      that an anonymous request remains outside staff search until its contact
-      checked.
+      address is confirmed, then enters the staff queue exactly once. Reusing
+      the confirmation link was idempotent, operator email remained disabled,
+      and exact cleanup left no matching request, history, audit, or mail-job
+      record.
 - [x] Database, application, worker, email, push, backup, and edge monitoring
       are visible through public readiness plus bounded aggregate metrics and
       the restore-verified backup heartbeat. The independent monitor timer is

docs/verification.md

@@ -3764,3 +3764,33 @@ promoted.
   release. No Play track, production service, frozen hackathon test deployment,
   shared Caddy configuration, or public Git remote was changed by these
   checks.
+
+# 2026-08-25 anonymous production support verification and cleanup
+
+- One uniquely addressed anonymous `account_access` request was submitted to
+  the production public-support form. Before contact confirmation, the exact
+  record had status `pending_verification`, no verified-contact timestamp, and
+  was absent from the staff-search result. Production operator-email mode was
+  observed as disabled.
+- The matching confirmation message reached Gmail Inbox with the existing
+  `Projects/WhoNeedHelp` label. Its copy explicitly stated that the request had
+  not yet entered the support queue, and its action used the production
+  `whoneedhelp.com` origin directly.
+- The first confirmation-link visit changed the exact record to `open`, made it
+  visible to staff search, added the expected `pending_verification -> open`
+  history event, and produced one `support_request.contact_verified` audit
+  event. A second visit to the same link was idempotent: the record remained
+  open, the two status-history rows and single verification audit row were
+  unchanged, and no duplicate mail job appeared. No operator-alert job was
+  present while operator-email mode was disabled.
+- Cleanup was guarded by the exact request UUID and reference and ran in one
+  database transaction. It removed exactly one support request, two status
+  events, one audit event, and one completed
+  `WhoNeedHelp.Mail.SupportConfirmationWorker` job; there were no conversation
+  messages. Follow-up queries returned zero matching requests, messages,
+  status events, audit events, and jobs. The synthetic confirmation message was
+  moved to Gmail Trash, and the two browser tabs created by the check were
+  closed.
+- The frozen hackathon test deployment, shared Caddy, public Git remote, real
+  users, and unrelated production support records were not changed by this
+  controlled verification.