feat(desktop): relay operator console as the single Moderation surface

[wpfleger96]

Adds an in-app admin console for relay operators and makes it the single Moderation surface under Settings. Operators authenticate with their own Nostr key over NIP-98 — no browser extension, no bearer token — to view deployment-wide moderation reports and product feedback, resolve/dismiss/escalate/reopen reports, update feedback status, and manage the operator/moderator staffing roster.

Nav bug this fixes

The moderation settings section was defined in settingsSections but never added to any group in settingsNavGroups, so the sidebar never rendered it and nothing deep-linked to it — the surface has been unreachable since #1617. This wires moderation into the Communities nav group (after community-members), repoints it at the relay admin console, and drops the separate admin-console section id so a single surface owns relay-level trust & safety.

Single Moderation surface

Relay operators/moderators are the only actors with a Moderation entry; the console is gated behind the relay OPERATOR/MODERATOR roles (RELAY_OPERATOR_PUBKEYS config → owner-fallback → relay_operators DB) and every /api/admin/v1/* route returns 403 to anyone else. Community self-administration (community-members / "Invites") and in-channel enforcement (the 9040–9043 signed commands) are a separate axis and are untouched.

The previously-duplicate community report queue (ModerationQueueCard + moderationQueue.ts and its three now-dead hooks — useModerationReportsQuery, useModerationAuditQuery, useResolveReportMutation) was unreachable dead code and is deleted in its own commit. useBanMemberMutation and the rest of features/moderation/hooks.ts remain — the members sidebar and message menu consume them.

Nav visibility gate

The Moderation entry renders only when the console can plausibly authorize:

• No origin (no NIP-11 advertisement, no saved manual origin) → hidden.
• Saved manual origin exists → always visible. The Advanced control that edits or clears a bad URL lives inside the surface, so a user who saved a wrong or token-mode origin can still reach the only UI that fixes their own state.
• Advertised-only origin → visible on nip98Authorized / disabled or a transport flake (networkOrIntercepted), hidden on a definitive non-admin verdict (nip98Denied / tokenMode / notAdminApi).

A probe network failure is never treated as unauthorized — a saved or advertised origin keeps the entry visible and lets the surface render its distinct error state rather than silently disappearing on a flake.

Discovery and connection

• On mount the console reads the connected relay's NIP-11 document for the optional admin_api field to auto-discover the origin — zero manual input on the happy path.
• The advertised origin is untrusted input: revalidated through AdminOrigin::parse before use; an absent or invalid value falls back to a manual field (pre-filled when discovery succeeds).
• A saved manual origin takes precedence over discovery — an operator's explicit choice is never overridden.

Auth and transport (Rust, src-tauri/src/commands/admin/)

• AdminOrigin value object: validates scheme + host + optional port, rejects credentials/path/query/fragment; http:// only for loopback, https:// otherwise.
• AdminRoute closed enum: no IPC surface accepts arbitrary URLs or paths, so the NIP-98-signed URL is byte-identical to the fetched URL.
• Dedicated no-redirect reqwest client as an SSRF guard: a relay 3xx is surfaced as an error and the NIP-98 header is never forwarded across origins.
• admin_probe targets the signed GET /probe endpoint and returns a typed state (nip98Authorized / nip98Denied / tokenMode / disabled / notAdminApi / networkOrIntercepted); nip98Authorized only on an authenticated 2xx, carrying the relay-resolved role/source from the ProbeResponse ({status, authMode, role, source, canAct, canStaff}, camelCase) so an operator reaches role/source badges and the Staffing tab. role/source are null in token/disabled modes. Strict typing of the probe body rejects unrelated JSON endpoints as notAdminApi.
• NIP-98 signing via AppState::signing_keys() (errors cleanly in recovery mode), with one retry on 401 using a fresh signed event.
• Response size bounded by a Content-Length preflight and a streaming byte counter; per-pubkey origin storage with atomic 0o600 writes.

Console UI (TypeScript, src/features/admin-console/)

• AdminConsoleSettingsCard: discovery + probe flow, per-pubkey state, role/source badges when authorized, honest copy for every probe state. The manual origin field is collapsed under an Advanced disclosure whose controls stay mounted.
• AdminConsolePanel with Reports / Feedback / Staffing tabs (Staffing gated on role === "operator"). Reports and feedback are grouped by community (communityHost) for cross-community triage.
• Reports: full action matrix per target_kind (event → delete/kick/ban/timeout/dismiss/escalate; pubkey → ban/timeout/dismiss/escalate; blob → dismiss/escalate). Kick removes the target from the report's associated channel, so it is suppressed when the report carries no channelId — the relay would reject it with invalid_action_for_target. A processing report row stays navigable — its enforcement state (pending/enforcing/succeeded/failed) lives inside the detail view, so the row must open. A failed action is always pre-mutation and offers a single Cancel & reopen button: it returns the report to open for a fresh resolution via POST /reports/{id}/cancel with {actionId} fencing the cancel to the observed action. There is no client-side retry — composing cancel + a new resolve would imply an atomicity the relay does not provide. pending/enforcing actions are owned by the relay recovery worker and offer no button; a 409 is authoritative and reloads detail. Each resolve attempt carries a client-generated requestId. Report and feedback lists refetch on back-navigation after a mutation so a resolved/dismissed status is reflected without a tab switch.
• Enforcement history: the report detail LATERAL returns the governing action even after the report leaves processing. A report enforced then reopened is open yet still carries its succeeded action — the ban actually ran, and a later reopen does not un-happen it. The console renders that action as executed-enforcement history and still shows the resolve form for re-triage; the resolve form gates on open status alone (a live/failed action keeps the report processing, never open).
• Reopen: terminal reports (resolved / dismissed / escalated) show a reopen form that moves the report back to open for re-triage via POST /reports/{id}/reopen. Reopen is re-triage only — it does not reverse any enforcement already applied, and the copy says so, more emphatically when the report carries an actionId. The per-attempt requestId is reused on a 409 (report moved to processing) so the relay dedupes.
• Feedback: list, detail, and status control (new/reviewed/archived) with a generation-fenced attachment viewer (image/* auto-loads; other MIME types load on demand). Feedback is deployment-global operator evidence: a purged source community severs communityId/communityHost to null rather than cascade-deleting the row, so severed rows bucket under a "source community removed" heading in the list and render em-dashes for the absent community fields in detail.
• Staffing: add operator (pubkey + role), roster with config / owner_fallback / db source badges; config-backed entries disable remove client-side and surface a 409 conflict as a human-readable message.
• Report, feedback, and enforcement actions confirm with sonner success toasts; mutation failures surface the relay's parsed error message through sonner error toasts rather than raw JSON in the component.

UI invariants

• The resolve form gates on open status alone. A live or failed action keeps the report processing (never open), so an in-flight enforcement never surfaces the form; a reopened-after-enforcement report is open and correctly shows both the executed-enforcement history and the form.
• A succeeded action on a terminal or reopened report renders as executed-enforcement history, not as inconsistent state — the enforcement ran and is reported honestly.
• Post-mutation delivery states render on a resolved report, never as an enforcement failure.
• tokenMode and disabled auth modes render read-only, with no action or staffing capabilities.

Related: #3777 (relay OPERATOR/MODERATOR role model + NIP-98 auth + admin_api NIP-11 advertisement — provides the runtime and the discovery field this console consumes)
Related: bb-public#339 (Phase 4 rollout config)