Enamel has exactly one live admin grant with zero headroom - decide whether a second is provisioned

Measured 2026-10-06 SELECT-only while designing ENAMEL-81: public.userGroups holds exactly ONE live enamel admin grant, identically under both the write-trigger predicate and the correct read predicate. Zero headroom, so fn_guardEnamelAdminMinimum is the only thing between the app and having no administrator, and it is one refusal away from blocking every legitimate admin change. ENAMEL-81 makes that guard correct; it cannot make the staffing safe. A second admin is NOT a code change: accounts are pre-created by a human and there is no auto-provisioning (grant+identity model is ACCOUNTS not PEOPLE), so this needs Elazar to name a second account that may truthfully hold the grant, then db-enamel to seed it. Raised by db-enamel-ca in review db-enamel-ca-muwp7lpgn5o3 as a PM call; filed here rather than left in a review body. Blocked on an Elazar decision, not on work.