[pedrosakuma]

Summary

Adds an admin frontend screen for outbound mutation reconciliation, so an operator no longer needs raw curl + a manually-extracted admin JWT (docs/RUNBOOK.md §0.1) to resolve a stuck outbound mutation.

Closes #785

What changed

• protocol.js: 5 new wrappers mirroring AdminOutboundMutationEndpoints.cs exactly — listOutboundMutations, getOutboundMutation, registerOutboundMutationEvidence, resolveOutboundMutation, approveOutboundMutationResolution.
• state.js: outboundMutations (list) and outboundMutationDetail (expanded row) slices, following the existing set*/notify convention.
• adminUi.js + index.html: new "Outbound mutation reconciliation" admin panel — filterable list (state / requiresReconciliation), expandable per-mutation detail (raw JSON of attempts/evidence/proposals/resolution), an evidence-registration form, and a propose-resolution form.
• app.js: handlers wired via setAdminHandlers, refreshOutboundMutations hooked into refreshAdminData(), status-code-specific feedback (401 → logout, 422 → invalid evidence, 409 → conflict, 503 → unavailable).

Maker/checker design (per discussion on #785)

Only the venue_absent decision is capacity-releasing and requires a genuinely different admin to approve (OutboundReconciliationService.Approve, server-side self-approval rejection). Unlike the existing killswitch/halt panels (same-user confirm() double-click), this UI implements "Propose resolution" and "Approve" as two separate actions:

• Approve is rendered per-pending-proposal.
• It is hidden client-side (UX hint only, not the enforcement point) whenever the proposal's makerRef equals the current session's username (session.username is populated from the same JWT sub claim the server uses as makerRef — confirmed via JwtIssuer.cs).
• The server remains the actual enforcement point regardless of what the UI shows.

Non-goals (unchanged from #785)

• No backend or auth changes — this is purely a UI over the already-implemented, already-tested admin API.
• No automated/bulk decision-making; every resolution requires an explicit operator-entered reason + evidence reference, mirroring the runbook.

Testing

• New frontend/test/outbound-mutations-ui.test.mjs (+ fixture frontend/test/fixtures/outbound-mutations.json):
  • Protocol-layer HTTP contract test (routes, methods, Authorization header) for all 5 new functions.
  • DOM-stub-based UI tests (pattern from operations-ui-states.test.mjs): list rendering incl. pending-approval badge, row-expand → detail load, and — the key design requirement — the Approve button is verified hidden when the current session is the proposer and shown (and wired to the right mutationId/proposalId) when a different admin proposed it.
• npm test (428/428) passes, including all pre-existing suites, in frontend/.

Not in this PR

Actually resolving FIRM01's 7 legacy stuck mutations (from the July 25 incident, root-caused in #773/fixed by #778) — that's an operational action for a real Entra-authenticated admin to perform via this new screen once merged/deployed, not something this PR does.

Protocol evidence gate

Does this PR add or change a dependency on B3MatchingPlatform / B3MarketDataPlatform wire behavior?

• No, this PR does not change cross-repo wire assumptions.
• Yes, and merged upstream evidence plus official schema details are listed below.

Checklist:

• Upstream issues, RFCs, or proposals are not the only evidence for implementation, or this PR has no cross-repo wire dependency.
• Participant-side / product requirements do not prescribe venue messages, templates, fields, or enums that do not exist in the official schema and merged upstream implementation.