Make role->capability map DB-owned, or add a cross-layer drift guard (CAPS vs fn_admin_invariant_ok)

Split off MARS-604 on audit-mars-ca's ruling (2026-08-03): the role->capability map (CAPS in src/lib/roles.ts) exists ONLY in TypeScript and has no DB representation. MARS-604's DB invariant fn_admin_invariant_ok() tests the literal lookupOptions value 'admin'; the caller-side self-demotion guard derives ADMIN_CONSOLE_ROLE_VALUES from CAPS. They agree today only because 'admin' is the sole adminConsole holder. FAILURE MODE: adding a second adminConsole-capable role updates the TS guard and NOT the DB invariant, silently. The DB then guards a narrower set than the UI does, and the last-admin protection stops covering the capability it appears to cover. Audit's ruling, verbatim in substance: a migration-level assertion is useful as a fail-loud check on the CURRENT one-to-one mapping but cannot prove the TS CAPS map, so it is insufficient as proof of future adminConsole coverage. Do NOT widen MARS-604 into a capability-table move; MARS-604 documents its invariant as the literal active 'admin' role plus a stated mapping assumption. SCOPE HERE: either make capabilities DB-owned (CAPS relocated to a real table/mapping the DB invariant reads), or add a durable cross-layer drift guard that fails loud when the TS map and the DB invariant diverge. Choice between the two is open; the second is much cheaper and may be sufficient. Not urgent: no second adminConsole role exists or is planned. The cost of leaving it is that the failure is silent when someone does add one.