feat(admin-console): Stage 2 — dashboard monitoring

Turn the console landing page into an operational dashboard.

- new internal/opsstatus: read-only Postgres projection via go-jet — ping +
  per-status COUNT/GROUP BY on runtime_records, mail_deliveries,
  notification_routes, and a malformed-intent count; degrades per-probe into
  Snapshot.Errors rather than failing the page
- dashboard renders backend readiness, database health, the three status
  tables, the malformed count, and any collection errors; falls back to a
  "monitoring not wired" note when no reader is injected
- AdminConsoleHandlers now takes an AdminConsoleDeps struct (Monitor + Ready
  added) so later stages add service refs without churning the signature

Tests: opsstatus store test against a Postgres testcontainer (empty schema +
one enqueued delivery); dashboard render tests with a fake reader (with and
without monitoring).

Docs: ARCHITECTURE 14.1 + FUNCTIONAL 10.2.1 (+ru) describe the dashboard.
(Prometheus /metrics exporters were already enabled in dev-deploy in Stage 1.)

docs/ARCHITECTURE.md

@@ -602,7 +602,13 @@ only the edge anti-abuse layer.
 State-changing requests are guarded against CSRF by a stateless token
 (HMAC-SHA256 over the authenticated username, keyed by
 `BACKEND_ADMIN_CONSOLE_CSRF_KEY`; a per-process random key is used when the
-variable is unset) plus a same-origin `Origin`/`Referer` check. See
+variable is unset) plus a same-origin `Origin`/`Referer` check.
+
+The console landing page is a dashboard that surfaces backend-visible
+operational signals — database reachability, per-status game-runtime counts,
+and mail/notification queue depths — read directly through the persistence
+layer; richer historical metrics come from the Prometheus exporters on
+`backend` and `gateway` (see [§17](#17-observability)). See
 `backend/docs/admin-console.md` for the console design.
 
 ## 15. Transport Security Model (gateway boundary)