Record production contact and operations evidence

docs/google-play-release-candidate-2026-08-09-v3.md

@@ -92,13 +92,14 @@ authenticated Play Console foreground-service form was saved with
 **User-initiated location sharing** and this URL. This does not claim Google
 approval.
 
-The remaining gates, rechecked read-only on 2026-08-14, are:
+The remaining gates, rechecked read-only through 2026-08-26, are:
 
 1. recheck the saved foreground-service declaration before submitting a new
    bundle or release and respond to any Play policy feedback;
-2. complete the Play Console public contact task; the Store listing is now
-   marked complete, the Dashboard reports 10 of 11 tasks complete, and Closed
-   testing remains locked;
+2. keep the public contact route monitored: Store settings contain
+   `contact@whoneedhelp.com`, and a controlled inbound test observed the exact
+   alias forwarding successfully to Gmail through ImprovMX. This verifies
+   receipt and forwarding, not a standalone mailbox or reply-from identity;
 3. recruit the required tester cohort only after Closed testing is unlocked;
    the Dashboard currently reports `0 testers currently opted-in`;
 4. keep Closed and Production tracks untouched until their separate gates are

docs/public-launch-checklist.md

@@ -80,6 +80,15 @@ In particular, a configured `SUPPORT_INBOX_ADDRESS` is not evidence of inbound
 mail delivery: verify its MX routing and complete a real receive-and-reply test
 before using it in Google Play or public support pages.
 
+The production public contact passed a controlled inbound-routing check on
+2026-08-26. Public MX resolved to ImprovMX, the exact
+`contact@whoneedhelp.com` alias forwarded a uniquely addressed message to the
+operator mailbox, the forwarding log recorded Gmail's successful SMTP receipt,
+and Gmail found the exact message. Random unconfigured local parts were
+rejected rather than forwarded through a catch-all. This proves the currently
+configured receive-and-forward path; it does not provide a standalone mailbox
+or prove reply-from identity.
+
 If the optional Brevo inbound path is selected, also verify the dedicated
 receiving subdomain, exact `SUPPORT_INBOUND_RECIPIENT`, authenticated webhook,
 provider `MessageId` deduplication, confirmation-gated staff visibility, and a

docs/verification.md

@@ -3828,3 +3828,50 @@ promoted.
 - The frozen hackathon test deployment, shared Caddy, public Git remote, real
   users, and unrelated production support records were not changed by this
   controlled verification.
+
+# 2026-08-26 inbound contact and production operations recheck
+
+- A controlled inbound-routing check used one uniquely titled technical
+  message addressed to `contact@whoneedhelp.com`. The existing ImprovMX
+  configuration showed the domain active, the exact contact alias forwarding
+  to the operator Gmail mailbox, MX priorities 10 and 20 for
+  `mx1.improvmx.com.` and `mx2.improvmx.com.`, and the configured ImprovMX SPF
+  include. No forwarding or DNS setting was changed.
+- The provider log recorded that exact message entering its queue at
+  2026-08-26 00:36:32 EEST and being forwarded to Gmail, whose destination
+  server returned SMTP `2.0.0 OK`. Gmail exact-subject search found the same
+  message with the project label. It was not present in Inbox. Provider logs
+  also showed unrelated random local parts rejected with `5.1.1`, rather than
+  forwarded through a catch-all. This proves the observed inbound forwarding
+  route; it does not establish a standalone mailbox or reply-from identity.
+- Public read-only probes returned HTTP 200 with the expected live and ready
+  payloads. The unauthenticated metrics endpoint returned the expected HTTP
+  401. Production application and edge containers were healthy with zero
+  observed restarts.
+- The external monitor's last DOWN transition covered two checks at 21:31 and
+  21:32 UTC on 2026-08-25: both its readiness and authenticated metrics
+  requests timed out, while backup freshness remained up. It recovered at
+  21:33 UTC. Production application logs independently showed successful
+  readiness traffic reaching the application throughout the same interval,
+  and the monitor's timed-out requests were absent from those logs. Together
+  these observations support a transient path failure between the external
+  monitor and production; they do not establish a production application
+  outage.
+- The workstation backup timer was loaded, enabled, active, and waiting. Its
+  scheduled 2026-08-26 00:00 EEST execution completed successfully after
+  catalog and checksum validation, encrypted off-server transfer, and the
+  isolated restore drill. The independent heartbeat had mode `0600`, reported
+  `restore_verified: true`, and the external monitor reported readiness,
+  metrics, and backup freshness all up against the operator-selected 36-hour
+  threshold.
+- An earlier stale-backup transition at 10:43 UTC on 2026-08-25 measured the
+  restore-verified heartbeat older than the configured 129,600-second limit.
+  The preceding scheduled archive and checksum had succeeded, but its isolated
+  restore database was still starting when the readiness check ran. The later
+  committed readiness helper waits for PostgreSQL initialisation and a direct
+  SQL probe against the final postmaster; its regression test exists in
+  `test/scripts/production_offsite_backup_readiness_test.sh`. A controlled
+  rerun recovered the monitor at 10:52 UTC, and the following scheduled run
+  passed as recorded above.
+- These checks did not change the frozen hackathon test deployment, shared
+  Caddy, production application, Play Console, or public Git remote.