Add Settings -> Database viewer (Adminer) for local devs and any admin

Local dev gets an unauthenticated Adminer instance bound to loopback
only. In production, any account with is_admin=true can open it -
the app mints a short-lived token from a live admin session, which
Nginx's new db.ciagent.org block exchanges for a session cookie that
re-checks admin status on every request, instead of a shared static
password that wouldn't scale to multiple admins or revoke live.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

KNOWN_LIMITATIONS.md

@@ -178,4 +178,11 @@ This file is updated as each phase lands. It exists so nothing is silently claim
 - **New `user_known_ips` table captures every distinct IP an account has signed in from** (`app/models/user_known_ip.py`), one row per `(user_id, ip_address)` pair with `first_seen_at`/`last_seen_at`, updated on every recorded sign-in (both real login and the local-dev bypass, gated by the same cooldown above for the latter). This is pure data capture for now - **nothing currently reads this table or surfaces it anywhere in the UI**; it exists as the foundation for a possible future "new device/location" security feature, per explicit request. `UserKnownIpRepository.record_login`'s return value (whether the IP was new) is already threaded through but currently unused by any caller.
 - **IPs were already being recorded per-login inside `user_security_events`** (every `login_success`/`login_failed` row has always carried `ip_address`) - `user_known_ips` doesn't replace that, it's a deliberately separate, deduplicated view: the security-events log is an append-only history of every attempt, while `user_known_ips` answers "what's the current set of IPs this account has ever used" without needing to scan and dedupe the (much larger, unbounded-growth - see the Phase 19 addendum above) events table.
 
+## Settings -> Database viewer (Adminer, local-dev/admin only)
+
+- **This feature deliberately does not reuse the app's own JWT/admin session to gate access, because it can't.** The frontend's access token lives only in `window.localStorage` (`apps/web/lib/api-client.ts`), never a cookie, and is attached only as a JS-constructed `Authorization` header on this app's own `fetch()` calls - a plain browser navigation to a different subdomain (`db.ciagent.org`) carries none of that. Instead, `apps/api/app/api/v1/db_viewer.py` mints a short-lived bootstrap token from a live, `require_admin`-gated session, which Nginx's `db.ciagent.org` block exchanges for an independent, cookie-based session scoped to that subdomain only. Both token types reuse the same `JWT_SECRET`/`TokenType` machinery as real login tokens (`apps/api/app/core/security.py`) rather than introducing a second signing secret.
+- **The `verify` endpoint re-loads the user and re-checks `is_admin` from the database on every request** (not just at token-mint time), so revoking someone's admin flag takes effect on their very next request through Nginx's `auth_request` - but a DB_VIEWER_SESSION cookie already issued is otherwise valid for its full 60-minute lifetime; there's no server-side session revocation list, only the live `is_admin` check and natural expiry.
+- **Local dev's Adminer (`docker-compose.yml`, port `127.0.0.1:8081`) has no authentication of its own at all** - it relies entirely on the port being bound to loopback only, matching this app's existing "loopback is inherently trusted" philosophy elsewhere (e.g. the local-dev auth bypass itself). Anyone who can reach `localhost:8081` on that machine - including another local user account on a shared machine - has full Postgres access with no further gate.
+- **Adminer itself has no read-only mode** - the feature was explicitly requested as "view and edit," so there's no additional restriction at the Adminer-config layer beyond Nginx's session gate (production) or loopback binding (local dev). The real Postgres username/password, required by Adminer's own login form, is the only remaining layer once past those.
+
 Further limitations are appended per-phase below.