feat(desktop): relay admin console for the /api/admin/v1 operator surface

[wpfleger96]

Adds a relay admin console under Settings — the single surface for relay-level operator work — replacing the previously unreachable moderation section. 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 reachability

The old moderation section id was defined in settingsSections but never wired into any group in settingsNavGroups, so the sidebar never rendered it — unreachable since #1617. This PR replaces it with a relay-admin section wired into the Communities nav group, pointing at the relay admin console, and drops the separate admin-console section id so a single surface owns relay-level trust & safety.

The Relay admin nav entry is always visible. Auth gates the panel itself; the nav entry is a door, not a credential — hiding it behind discovery state would strand an operator whose relay transiently fails NIP-11 discovery with no path back to the connection settings.

Discovery and connection

On mount the console reads the connected relay's NIP-11 document for the optional admin_api field. When a valid origin is discovered and its host matches the connected relay's host (case-insensitive, host identity only), it is automatically saved and probed — the panel renders immediately with no Save step required. A cross-host advertisement is pre-fill only: it populates the manual origin field under Advanced and is never saved or probed without an explicit Save, so a relay cannot direct an unconsented NIP-98 signature at a third-party origin; residual exposure on the same-host path is bounded by NIP-98's URL/method/payload binding. Saving is only required for manual origin changes. The advertised origin is untrusted input: revalidated through AdminOrigin::parse, falling back to manual entry when absent or invalid. A saved manual origin always takes precedence over discovery.

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. The relay side normalizes its configured admin host at config load and compares inbound Host/Origin hosts case-insensitively.
• AdminRoute closed enum: no IPC surface accepts arbitrary URLs, 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 an error and the NIP-98 header never crosses origins.
• admin_probe signs GET /probe and returns a typed state (nip98Authorized / nip98Denied / tokenMode / disabled / notAdminApi / networkOrIntercepted). The response body is validated against the full relay contract — nip98Authorized only when the complete NIP-98 invariant holds, disabled only on a coherent disabled-mode body; any incoherent or unrelated JSON classifies as notAdminApi, so the console never fails open at the network boundary. Unknown fields are tolerated for forward compatibility.
• NIP-98 signing via AppState::signing_keys(), one retry on 401 with 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.

Relay admin console

The console is gated behind the relay OPERATOR/MODERATOR roles from #3777; 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 three dead hooks) was unreachable dead code and is deleted in its own commit; useBanMemberMutation and the rest of features/moderation/hooks.ts remain in use by the members sidebar and message menu.

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

• AdminConsoleSettingsCard: discovery + probe flow, honest copy for every probe state, manual origin under an Advanced disclosure at the bottom. The role (operator/moderator) is rendered in the connection status line as plain text ("Connected as operator") — no badge-shaped elements above the tab row. The origin provenance (relay config / database) appears inside the Advanced card as small muted text. Section title changed to Admin.
• AdminConsolePanel with Reports / Feedback / Staffing tabs (Staffing gated on role === "operator"); reports and feedback grouped by community for cross-community triage.
• Reports: always requests scope=all so the existing resolve/cancel/reopen controls can reach every status (open, processing, resolved, dismissed, escalated). The relay's omitted-scope default is escalated-only (the platform-safety backstop); scope=all is explicit and scoped to this console. Full action matrix per target_kind (event → delete/kick/ban/timeout/dismiss/escalate; pubkey → ban/timeout/dismiss/escalate; blob → dismiss/escalate); kick is suppressed when the report carries no channelId. A processing row stays navigable — enforcement state lives in the detail view. A failed action (always pre-mutation) offers a single Cancel & reopen via POST /reports/{id}/cancel with {actionId} fencing; there is no client-side retry. pending/enforcing actions belong to the relay recovery worker and offer no button; a 409 reloads detail. Lists refetch on back-navigation after a mutation.
• Report failure UX: reportErrorMessage() strips 4xx/5xx status prefixes and surfaces the relay's own error reason in the toast (e.g. relay returns "400: you cannot report this content" → toast shows "you cannot report this content"). Self-report blocking UI removed — the relay has no self-report gate, and the failure was purely client-side error surfacing.
• Reason audience disclosure: the Reason (optional) field shows exact copy under the input based on selected action — Delete discloses that reason is sent verbatim to the affected user and posted publicly in the room; Kick/Ban/Timeout disclose affected-user only; Dismiss/Escalate disclose reporter only. These mirror the actual relay notice paths.
• Enforcement history: the report detail carries the governing action even after the report leaves processing — a report enforced then reopened is open yet still shows its succeeded action as executed history alongside the resolve form; a reopen does not un-happen a ban. The resolve form gates on open status alone.
• Reopen: terminal reports (resolved/dismissed/escalated) can be returned to open for re-triage via POST /reports/{id}/reopen. Reopen never reverses applied enforcement, and the copy says so.
• Feedback: list, detail, and status control (new/reviewed/archived) with a generation-fenced attachment viewer. A purged source community severs provenance to null rather than deleting the row; severed rows bucket under a "source community removed" heading.
• Staffing: Add is create-only with display names resolved via useUsersBatchQuery and npub cross-fade on hover (HoverStaffingIdentity). An entered key that already appears in the authoritative roster (config, owner-fallback, or DB) is rejected locally with an inline duplicate-key message and no request is issued; a 409 Conflict from add, role change, or remove surfaces the relay's parsed error body via adminErrorMessage(e) — distinguishing config-backed key conflicts from last-operator conflicts without HTTP-status inference. Roster with config/owner_fallback/db source labels; config-backed entries disable remove client-side. In-place role change via <select> calling putAdminOperator; the relay responds with the effective OperatorEntry (pubkey, effectiveRole, sources) in the same shape as the roster list. Read-only badge for config-managed entries.
• Timeout expiry: useTimeoutState clears the store when derived state is INACTIVE but the store is still active; the 1s tick is scoped to entries with a known expiresAtMs and owned by ComposerTimeoutBanner (mounted only while a timeout is active), while ChannelPane subscribes to the boolean useTimeoutActive() — the pane re-renders when a timeout starts or ends, not every second. useMembersSidebarModeration ticks nowMs only while the sidebar is open, the viewer can moderate, and some member has a future mutedUntil; the tick after the last expiry stops the interval.
• Mutations confirm via sonner toasts; failures surface the relay's parsed error message, not raw JSON. tokenMode and disabled auth modes render read-only.

Mutation idempotency

Resolve and reopen carry a per-attempt requestId. On first submit the whole command ({requestId, action, reason, expirationSecs}) is frozen; after an ambiguous failure (409, 5xx, transport error, truncated response) the snapshot is retained, action/reason/duration controls are locked, and the retry sends the exact same payload byte-for-byte. A definitive pre-commit rejection (non-409 4xx with bodyComplete: true) discards the snapshot, unlocks controls, and the corrected submit uses a fresh payload. On success the toast derives from the authoritative AdminReportResolution (activeAction.action when present; otherwise status for decision-only outcomes) — never from the mutable form selection.

The native mutation commands — including operator delete — reject with a typed AdminMutationError carrying the relay's HTTP status (relayStatus, null when no verdict exists) and a bodyComplete flag that is true only when the full response body was read.

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)

Screenshots

Captured headless at 197f0ba0c against the mock bridge (1280×720).

Setup

Origin setup — Advanced disclosure open, idle state

Authorized console — all three tabs

Reports

Reports queue — open, processing, resolved across two relay groups

Open report detail — reporter, target, message snapshot, resolve form

Processing report — PROCESSING/HARASSMENT, ban enforcing state

Resolve form — Delete selected, audience disclosure copy

Resolved report — enforcement history block

Feedback

Feedback list — community grouping with status badges

Feedback detail — mutable status control (operator mode)

Feedback detail — passive status badge (read-only/disabled mode)

Staffing

Staffing roster — config/owner_fallback/db source labels

Add form — new pubkey filled, ready to submit

Duplicate rejection — inline error for existing principal

Post-review fixes

P2: stale principal after self-demotion/removal — AdminConsolePanel now accepts an onSelfMutation callback and passes it to StaffingTab. After a successful role change or removal targeting the current principal's own pubkey, the callback fires runProbe(savedOrigin) in the parent, refreshing the role badge and tab visibility (Staffing tab disappears on self-demotion) without any manual re-probe.

P2: 409 misclassification in Staffing — The adminMutationRelayStatus === 409 hardcode in all three mutation paths (handleRoleChange, handleConfirmRemove, handleAdd) is replaced with adminErrorMessage(e). A 409 now surfaces the relay's parsed error body directly — distinguishing config-backed key errors from last-operator conflicts. Previously, both 409 variants showed the same "config-backed" copy, hiding the relay's "add a replacement operator first" recovery guidance when it was a last-operator conflict.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not auto-probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-949

  admin_api is explicitly untrusted NIP-11 data, but discovery applies the same permissive policy as manual operator input: HTTP loopback is accepted and every HTTPS host is accepted. Both the nav resolver and settings card then probe that value automatically without confirmation (hooks.ts:45-56, AdminConsoleSettingsCard.tsx:303-316). A malicious connected relay can therefore make the native client contact http://localhost:<port> (the client pins localhost to 127.0.0.1) or HTTPS private/link-local targets. If the target returns 401 WWW-Authenticate: Nostr, the app sends it a fresh app-key signature, adding a signing oracle and pubkey-ownership disclosure to the SSRF. Separate advertised-origin validation from manual configuration: do not auto-probe loopback/private/link-local advertised destinations, and account for DNS resolution/rebinding, or require explicit operator confirmation before any cross-origin probe. Keep the loopback HTTP carve-out only for manual origins.

• [P2] Actually make disabled-auth mode read-only — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:397-480

  disabled currently renders the same AdminConsolePanel as an authorized principal, with only the staffing tab hidden. The report resolve/reopen/cancel controls and feedback status controls remain enabled, although the related relay contract intentionally rejects every mutation in disabled mode with 403. This contradicts the PR’s stated read-only behavior and presents controls guaranteed to fail. Pass a read-only capability into the panel and suppress/disable all mutation affordances when the probe result is disabled.

The command registration/API seams, identity and async fencing, report lifecycle/idempotency paths, attachment cleanup, navigation, staffing gating, and legacy-surface removal were otherwise coherent in this read-only diff review. GitHub currently exposes only a passing DCO check for this head; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Two security/resource-boundary blockers remain on this head:

1. Do not auto-probe a relay-advertised admin origin under the manual-origin trust policy. The NIP-11 admin_api value is explicitly untrusted, but admin_origin_from_nip11 passes it through the same AdminOrigin::parse policy used for operator-entered values. That policy accepts loopback HTTP and unrestricted HTTPS hosts. Both the navigation resolver and the settings card then automatically probe the advertised origin, and the probe performs a native GET before sending a fresh NIP-98 signature when the target replies with 401 WWW-Authenticate: Nostr. A malicious connected relay can therefore advertise http://127.0.0.1:<port> / localhost (the client explicitly pins localhost to 127.0.0.1) or an HTTPS private/link-local target and trigger zero-click native SSRF; a cooperating target also gets an attacker-triggered signing oracle and proof of the app pubkey. This is not hypothetical policy drift: mod_tests.rs currently asserts that a loopback origin from NIP-11 is accepted and returned for automatic probing. Please separate advertised-origin validation from explicit manual configuration: never auto-probe loopback/private/link-local advertised destinations, and account for DNS rebinding, or require an explicit operator confirmation before any cross-origin probe. Keep loopback HTTP only for a manually entered origin.

2. Bound attachment preview work across the whole feedback item, not only per response. parseImetaAttachments accepts and returns every valid imeta tag, FeedbackDetail mounts an AttachmentViewer for every result, and each image/* viewer immediately starts its own native fetch. The Rust command caps each response at 10 MiB, but there is no attachment-count, aggregate-byte, or concurrency bound. The relay’s feedback ingest bounds serialized tags to 64 KiB but does not cap the number of imeta entries, so an admitted feedback event can fan out many simultaneous image reads and retain their blob URLs until navigation. The existing test explicitly blesses multiple tags but covers no aggregate/concurrency ceiling. Please impose a small count plus aggregate-byte budget before rendering/fetching, avoid unbounded parallel auto-load, and add a regression showing excess attachments are not requested.

The closed route construction, exact-body NIP-98 binding, no-redirect client, mutation idempotency/recovery fences, and identity/origin React state fences otherwise held in this read-only diff review. GitHub currently exposes only the passing DCO check for this head; I did not execute PR code under the automation policy.

Accidental duplicate from a concurrent automated recovery. The earlier marked review 5032499207 is authoritative.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not automatically probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-950

  admin_api is untrusted NIP-11 data, but discovery runs it through the manual-entry policy, which accepts loopback HTTP and every HTTPS host (origin.rs:64-90). With no saved origin, both the settings surface and navigation resolver automatically probe the advertised value (AdminConsoleSettingsCard.tsx:284-316, hooks.ts:41-56). The native probe first GETs that attacker-selected destination and, if it answers 401 WWW-Authenticate: Nostr, sends a fresh NIP-98 signature to it (mod.rs:160-215). A malicious or compromised connected relay can therefore target localhost, private/link-local addresses, or an attacker hostname that resolves there; no-redirect handling does not constrain this initial destination. Separate advertised-origin trust from explicit manual configuration: require an explicit confirmation or prove/bind the advertised endpoint to the connected relay, and reject resolved loopback/private/link-local/reserved targets with rebinding-safe connection handling. Add advertised-origin tests for loopback, RFC1918/link-local, and a public hostname resolving privately. The existing discovery test currently blesses automatic loopback probing (mod_tests.rs:872-916).

• [P1] Bound attachment fan-out across the feedback item — desktop/src/features/admin-console/AdminConsolePanelHelpers.tsx:243-272

  parseImetaAttachments returns every valid imeta tag, FeedbackDetail mounts every result (AdminConsoleFeedbackTab.tsx:420-465), and each image/* viewer immediately starts its own native fetch on mount (AdminConsoleFeedbackTab.tsx:215-224). The 10 MiB native cap is per response, with no attachment-count, aggregate-byte, or concurrency ceiling. A single admitted feedback event can therefore trigger many simultaneous native reads and retain all resulting blobs until navigation. Impose a small item-wide count/aggregate budget and bounded fetch concurrency (or explicit loading), then add a regression proving excess attachments are not requested.

• [P2] Keep disabled-auth mode read-only as documented — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:470-480

  A coherent disabled probe mounts the same panel as an authorized principal without passing a read-only capability. Report resolve/reopen/cancel and feedback status controls therefore remain live, although the relay rejects mutations in this mode. This contradicts the documented contract that disabled mode renders feedback status read-only (docs/admin/README.md:267-276) and the PR description. Pass the auth capability into the panel and hide or disable every mutation affordance while preserving reads.

• [P2] Expose the selected feedback status programmatically — desktop/src/features/admin-console/AdminConsoleFeedbackTab.tsx:352-375

  The current status is communicated only through button styling (variant and ring classes). The three ordinary buttons have no aria-pressed, radio semantics, or textual current-value output, so a screen-reader user cannot determine the active status before changing it. Add a programmatic selected state and assert that semantic contract rather than only the visual class.

The closed route construction, exact URL/body NIP-98 binding, no-redirect client, response caps, identity/origin async fences, report lifecycle and request-ID recovery contract, role-gated staffing, and legacy moderation-surface removal were otherwise coherent in this read-only exact-head review. Desktop, Rust, build, and desktop integration checks are green; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested at exact head 63db828a09b270239d5e56bf82c3f5e8468cea43 and exact base a3730784fc851bb1125b40cca9b0a30788a293c1.

P1: require confirmation before removing an operator

The Staffing trash button calls handleRemove directly, which immediately invokes deleteAdminOperator (desktop/src/features/admin-console/AdminConsoleStaffingTab.tsx:105-121,203-224). One stray click therefore deletes a DB-backed operator, potentially the acting operator, without a confirmation, target/role recap, or undo. That can remove administrative access and may require another operator or out-of-band configuration to recover.

Put this destructive authorization change behind an explicit confirmation dialog. Make self-removal especially clear, and add cancel/confirm behavior tests. The current event suite only checks whether staffing controls are rendered; it does not exercise removal confirmation.

P2: recover when the active Staffing tab becomes unauthorized

activeTab persists independently of role (AdminConsolePanel.tsx:832-843). If the same mounted panel changes from operator to moderator/unknown while Staffing is selected, the tab button disappears and the content is suppressed (AdminConsolePanel.tsx:859-887), leaving an empty panel with no selected visible tab. Reset an invalid active tab to Reports when role/capabilities change and cover that prop transition.

The previous advertised-origin SSRF, attachment fan-out, disabled-mode mutation, and feedback-status accessibility blockers are otherwise closed at this head. Relay discovery is now prefill-only until an operator explicitly saves the origin; item-wide attachment limits, read-only mutation gating, and aria-pressed are present. Hosted substantive checks are green. This was a read-only review of immutable GitHub source/diffs; no PR code was checked out or executed.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two P2 Staffing defects

Reviewed head efa68d25829d357b7b557cbe92eb2e48cd094be0 against base 3c7f288c60d67df78577b237e27c3dfc8831aaa1, focusing on changes since reviewed head b0b5d6467ea6f87c58f86f62b796a13a319e761c and the agreed integration contracts. Relay operator/moderator authority remains separate from community administration; the relay is authoritative for permissions and mutation outcomes.

P2: Refresh the active principal after successful self-demotion (unresolved)

Staffing’s successful role change only increments its roster generation. With two effective DB operators A and B, sign in as A and change A to moderator. The PUT succeeds, then the operator-only roster reload returns 403, but Settings still says Connected as operator and retains Staffing. The parent’s role comes exclusively from its previous probe; no mutation callback refreshes it. This is stale authorization presentation, not a server authorization bypass. Successful self-removal has the same reconciliation gap.

Exit: after changing/removing the current principal, refresh the parent probe and reconcile visible tabs/access. Exercise the actual Settings → Staffing mutation → principal transition, asserting moderator status and Reports/Feedback without Staffing (or denied state after removal). The existing role-downgrade test manually supplies a new role prop, so it cannot catch the missing upstream update.

P2: Preserve the last-operator conflict’s recovery instruction (new regression)

The new role-change 409 branch and remove branch classify every typed 409 as a config-backed key. With no effective config operator and one DB operator, attempt to demote or remove that operator. The relay correctly rejects it with “add a replacement operator first” (PUT, DELETE). The UI instead claims this mutable DB row is config-backed, hiding the supported recovery and directing the operator toward the wrong cause.

Exit: display the relay’s parsed error message for these conflicts, or distinguish a stable conflict reason rather than treating HTTP status as one. No broader transport redesign is needed. Cover both immutable-config and last-operator responses for role change/removal; the new 409 tests currently encode only the immutable interpretation.

Fixes, boundaries, and validation

Cross-host discovery now requires explicit Save, closing the prior automatic cross-host/.localhost signing path. Intentional same-host discovery, including another port, is not a finding. The discovery DNS check is not connection-time address binding, but the proposed additional proof-disclosure scenario requires a TLS endpoint valid for the already-trusted hostname; no additional credential capability was established. Treat that as non-blocking hardening, preserving manually trusted internal origins.

The report extraction preserves the prior implementation and frozen retry/action contracts. Inspected timeout/banner/sidebar lifecycle changes and new reactive tests; no additional defect established. Native bodyless DELETE retains its wire/signing contract. Independent lanes were integrated. Validation was exact-source/diff and test-source inspection only: no PR checkout, build, test execution, or live workflow. Unrelated rebase changes, separate community moderation as a whole, and mobile/web operator interfaces were excluded.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: one P2 origin-switch regression

Reviewed head 78da302e53aea6b90a37ff38757762977f8cbf35 against exact base/merge-base 5079c770fe30bb3d8204822ce6c2431eacac6d4b, focusing on the corrective delta since efa68d25829d357b7b557cbe92eb2e48cd094be0. Relay staffing remains distinct from community administration, and each relay is authoritative for its own principal’s permissions.

P2: Fence the self-mutation refresh to its original origin/session

The new Settings callback captures savedOrigin, but Staffing invokes that callback after awaiting its mutation, including after the panel has unmounted. Advanced/input/Save remain usable during the mutation.

Reproduction: with two effective operators on relay A and the current identity independently authorized on relay B, start self-removal on A and delay its successful response. Save B as the admin origin and let B’s probe authorize. When A’s DELETE resolves, the retained callback calls runProbe(A). That starts a fresh probe, superseding B’s probe/state; A now returns denied. Settings still has B saved but displays Access denied and hides B’s otherwise-authorized console. Self-demotion similarly lets A’s moderator result hide Staffing on B where the identity is still an operator.

The existing probe abort check does not fence this: the stale callback creates the newest controller. The origin edit unmounts the child, not the Settings session, and the callback does not check the current session/origin. This is a user-visible cross-origin state regression introduced by the refresh wiring, not a server authorization bypass. Re-probe recovers it, but the wrong denial/role persists until then.

Exit: ignore a self-mutation completion if its captured origin/session is no longer current, before it starts a probe. Reuse the existing context-fencing pattern rather than adding a new lifecycle owner. Add a Settings-level deferred-mutation regression: authorize B before settling A’s mutation, then assert B’s authorization/panel survives and the stale completion cannot replace it.

Resolved findings and validation boundary

The previous two P2 findings are fixed on the ordinary same-origin path: self-demotion/removal now refreshes the parent principal, and Staffing preserves the relay’s distinct immutable-config versus last-operator recovery text. The new Settings-level self-demotion test exercises the actual parent wiring. Production source is unchanged between 0ab00433 and 78da302e; that last commit adds tests only.

This was source/diff and test-source inspection on the pinned Blox host, with independent metadata review. No PR checkout, build, test execution, or live reproduction was performed. The one-time exact-head CI snapshot had 53 successful checks, 27 skipped, and two still running; it is not an all-green claim. Existing accepted discovery/trust behavior and unrelated base changes were not reopened. The sole requested fix is the stale-origin callback above.

addressed

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: origin/session callback blocker resolved

Reviewed head be0b4833045fc7f993c9e80c1f7ac7dea33c318c against exact base 77729abfb692b25a0f4ec4a69add86af2e32c0dd, focusing on the corrective delta since review 5269776708 and the intervening main merge. No remaining blocking defect found in that bounded scope.

• Origin switch: the Settings callback checks its captured origin against the synchronously maintained current-origin ref before starting a probe. A delayed self-removal/demotion on A can no longer replace B’s authorization after B is saved. The Settings → Panel → Staffing regression authorizes B before settling A’s DELETE, then checks the probe count, targets, and surviving panel.
• Session teardown: the existing unmount cleanup now clears that same ref. A retained mutation callback cannot start a fresh probe from the retired Settings session after an identity change. The added production-seam test unmounts before resolving DELETE and asserts no additional probe. Ordinary live-session self-mutation still refreshes principal state; parsed last-operator versus immutable-config 409 recovery messages remain intact.
• Integration: the main merge has no manual resolution delta. The resulting relay router retains both the feature’s operator routes and main’s adjacent member-restriction routes. Previously reviewed report recovery, discovery/transport, and staffing implementations are unchanged where verified by blob identity. Same-host discovery, explicit Save for cross-host advertisements, manual internal origins, and separate relay/community authority remain the accepted contract.

Validation limits: immutable source/diff and test-source inspection on the pinned Blox host, with independent metadata review and coordinator verification. No checkout, build, test execution, or live reproduction. The teardown regression is not StrictMode-wrapped; a separate StrictMode Save test and the load-effect ordering cover re-arming, not a combined StrictMode/self-mutation runtime test. No speculative same-identity A→B→A finding was promoted into a blocker. Unrelated mainline changes and separate mobile/web operator UX were excluded.

CI is not certified green. The frozen exact-head snapshot at 2026-09-21 20:02:32Z showed 31 successful checks, 19 skipped, one failure, and four in progress. Desktop Domain / Desktop Smoke E2E (3) failed; its cause is unclassified here. No polling or reruns were performed. This source-review clearance does not waive CI or constitute approval.