docs(authentik,openwebui): the roles claim mints the OpenWebUI role

Provisioned jason (pk 24, human-user template) and drove his first SSO
login in a clean browser: the row appeared as role='user' with chat and
wilwheaton TTS working, no manual step. The pending-then-flip law is
therefore wrong for a claim-carrying account - ENABLE_OAUTH_ROLE_MANAGEMENT
+ the roles scope decide it, and 0.12.5 refuses a claim-less login with 403
instead of falling back to ui.default_user_role. Census gains jason.

serverAppConfigs-docs/Dankclaw/OpenWebUI.md

@@ -216,18 +216,26 @@ browser-driven and only touches the two exempt vhosts (`ai.` and `auth.`).
   into the existing local account with the same email — the pre-SSO admin
   (frank8465@protonmail.com) keeps its data. `ENABLE_OAUTH_SIGNUP=true` lets
   other `openwebui_users` create accounts on first login.
-- **First login mints role `pending`.** `ui.default_user_role=pending` (config
-  DB, verified 2026-10-09), so a freshly-provisioned `openwebui_users` account
-  completes SSO and then cannot chat (picker empty) until its role is flipped:
-  `UPDATE "user" SET role='user' WHERE email='<user>@franksdank.cloud';` —
-  run with host `python3` over ssh against
+- **First login mints the role from the claim, not from
+  `ui.default_user_role`.** The quadlet sets `ENABLE_OAUTH_ROLE_MANAGEMENT=true`
+  and `OAUTH_ROLES_CLAIM` defaults to `roles`, so the `roles: ["user"]` claim
+  decides the role. Measured 2026-11-04: a freshly-provisioned
+  `openwebui_users` account completed SSO in a clean browser and the row
+  appeared as `role='user'` — chat answered and Read Aloud synthesized, with no
+  manual step. `ui.default_user_role=pending` (config DB) is the fallback for an
+  account the claim does *not* describe, and 0.12.5's `get_user_role` **refuses
+  the login with 403** when role management is on and no roles claim is
+  readable — so "SSO succeeded but I cannot chat" points at a missing
+  `openwebui_users` group/entitlement, not at a row waiting to be flipped. Flip
+  only a row that is actually stuck:
+  `UPDATE "user" SET role='user' WHERE email='<user>@franksdank.cloud';` — run
+  with host `python3` over ssh against
   `/home/dank/Containers/open-webui/data/webui.db` (no `sqlite3` CLI on
-  Dankclaw; table is `user`, singular; no `active` column). No per-user model
-  grant is needed: the picker model `frank-zealot` carries the global
-  `access_grant` row `(model, frank-zealot, user, *, read)`, so any
-  `role='user'` account sees it. Flip on FIRST-LOGIN SIGHTING — the row does
-  not exist until the account signs in (2026-10-09: five provisioned accounts
-  had no row).
+  Dankclaw; table is `user`, singular; no `active` column). The row does not
+  exist until the account signs in, so census it after a first-login sighting
+  (2026-10-09: five provisioned accounts had no row). No per-user model grant is
+  needed: the picker models carry the global `access_grant` row
+  `(model, <id>, user, *, read)`, so any `role='user'` account sees them.
 - **IdP reachability:** the container is on its own bridge (10.89.3.0/24) and
   cannot reach `authentik-server:9000` by name. It reaches the IdP over the
   public URL `https://auth.franksdank.cloud` — Caddy publishes `0.0.0.0:443`