Warn users before session/privileged-session/login-flow timeouts and allow re-authentication (WCAG 2.2.1)

Context

Accessibility audit of the frontend admin UI found that none of Rafiki's three Kratos-enforced time limits give any warning or way to extend before the user is force-redirected. This is a WCAG 2.2.1 (Timing Adjustable) gap.

Short, security-driven session limits are appropriate for a financial admin dashboard — the issue isn't the limits themselves, it's that they fire with no warning and no in-context way to continue.

The three limits (Ory Kratos config)

1. 1-hour session limit — session.lifespan: 1h
2. 15-minute privileged-session window — selfservice.flows.settings.privileged_session_max_age: 15m (required recency-of-auth for sensitive Settings actions like password change)
3. 10-minute login-form window — selfservice.flows.login.lifespan: 10m (how long an unsubmitted login flow at /auth/login stays valid)

Set identically across all four kratos.yml configs under localenv/.

Current behavior

checkAuthAndRedirect (packages/frontend/app/lib/kratos_checks.server.ts) is a passive, per-request gate — it calls Kratos's /sessions/whoami and redirects to /auth if the session isn't active. It's invoked from root.tsx's loader (effectively every navigation) plus auth._index.tsx, auth.login.tsx, auth.recovery.tsx, auth.manual-logout.tsx, and settings.tsx. There's no client-side timer/countdown — an idle user only discovers the session expired on their next navigation or submit, with no warning.

Proposed approach

Per the audit recommendation, provide advance warning and let users actively re-authenticate (rather than silently extending):

• Surface expires_at / authenticated_at from Kratos's whoami response through the relevant loaders to the client.
• Add a warning dialog + countdown: global (root.tsx) for the 1-hour session, scoped to settings.tsx for the 15-minute privileged window, and on auth.login.tsx for the 10-minute login-form window.
• "Continue" redirects into Kratos's native re-auth flow (/auth/login?refresh=true&return_to=...), which renews the session without a new backend endpoint.
• The 10-minute login-form case may warrant a lighter treatment (auto-fetch a fresh flow + repopulate typed fields on expiry) since no authenticated work is at risk there — confirm this is acceptable before scoping it down.

Reusable pieces to build on: ConfirmationDialog.tsx / RedirectDialog.tsx (accessible dialogs) and Snackbar.tsx's timeout pattern.

Start with packages/frontend/app/lib/kratos_checks.server.ts and the loaders in root.tsx, settings.tsx, and auth.login.tsx; trace how Kratos whoami data reaches the client. Review ConfirmationDialog.tsx, RedirectDialog.tsx, and Snackbar.tsx for existing UI patterns, and inspect the four localenv/kratos.yml files for the configured lifespans. Done means each applicable timeout warns before expiry and offers the specified re-authentication path, with the login-flow treatment confirmed.