[Feature] Admin incident-review and pause-authorization UI for the security circuit breaker

[Sendi0011]

Summary

The automated incident-response circuit breaker (merged in PR #259) is fully wired server-side but invisible in the UI. An admin monitoring a pool can see security alerts on the admin security page, but there is no screen to review an incident, act on it (resolve / resume / record the on-chain hash), or pre-authorise / revoke the automatic on-chain pause.

The backend already exists and is complete:

• GET /api/admin/incidents?poolId=&callerAddress= — review queue
• POST /api/admin/incidents/[id] — resolve, resume, record_onchain
• GET/POST /api/admin/pause-authorizations — register, list, revoke (armed status)

There is no frontend for any of it. When the breaker auto-pauses a pool the admin receives a notification, but has nowhere to open it from.

Requirements

1. Incident review screen under the existing /dashboard/admin/security area: list incidents for a pool, showing severity, alert count, trigger rules, the decision reason, executed/dry-run state, onchain_status, cooldown/skip_reason, and timestamps — surfaced from GET /api/admin/incidents.
2. Act on an incident: resolve (required note), resume (platform → active, flagging when onchainUnpauseRequired so the admin knows the contract stays paused), and record the tx hash of the on-chain pause/unpause they signed. Wire to POST /api/admin/incidents/[id], using the existing signMessage proof helper where the endpoint expects a wallet action.
3. Pause-authorization panel: show armed state per pool, list each authorization with its status (active/used/expired/revoked) and ledger expiry, sign a new one in-browser via signPauseAuthorization (reuse frontend/lib/pause-authorization.ts and @/components/web3-provider's kit), and revoke with the SEP-53 message proof (signRevokeProof).
4. Primary CTA: make the pool-paused notification/deep-link land on this review screen, and show a banner (mirroring archived-pool-banner.tsx) when a pool is in paused status with a pause_reason, telling members what happened.
5. i18n: add EN + ES strings under the existing admin namespace (frontend/messages/en.json, es.json).

Notes / context

• Follow the existing admin/security/page.tsx and security-alert-card.tsx conventions (data fetching, layout, accessibility).
• The API routes already do server-side auth (creator check) and rate limiting — the UI should pass callerAddress and handle 403s gracefully.
• The entry XDR is never returned by GET; the UI must not try to display it.
• Component tests would be valuable here (the codebase uses Vitest + RTL, e.g. frontend/__tests__/deposit-calendar.test.tsx), covering the incident status mapping and the authorization armed/status rendering.

Acceptance criteria

• Admin can open, review, and act on incidents for a pool they own (resolve / resume / record on-chain hash)
• Admin can pre-authorise, list, and revoke the automatic on-chain pause from the UI
• A paused pool shows a banner with its pause_reason, and notifications link to the review screen
• EN + ES translations present
• Component tests cover incident status mapping and authorization status rendering
• Lint, format, and all CI checks pass

[Clement-coder]

Hi,
I'm a full-stack software and blockchain engineer with experience delivering production-grade solutions across frontend, backend, infrastructure, analytics, and blockchain systems.
I'd like to take ownership of this issue. I've reviewed the requirements and have a clear approach for implementing a robust, scalable, and maintainable solution that satisfies all acceptance criteria. I'll ensure the implementation follows project conventions, includes comprehensive testing, and is properly documented.
I can start immediately and will provide consistent updates throughout development. Looking forward to contributing to the project.

[morelucks]

Hello,

I’m a smart contract and full-stack developer interested in contributing to this issue.

I have experience contributing through OnlyDust and have participated in Drips Wave 1, Wave 2, Wave 5, as well as the GrantFox beta campaign.

My technical background includes Rust, Soroban, Cairo, Solidity, and TypeScript, with a focus on building secure, scalable, and maintainable blockchain applications.

Based on the scope of this issue, I’m confident I can deliver a complete and well-tested solution within 8hours of assignment. I prioritize clean code, clear documentation, and efficient implementation.

I’d appreciate the opportunity to contribute and help move this issue forward.

Thank you.

[grantfox-oss]

🦊 GrantFox — @morelucks has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #261)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.