docs: Grafana reads claims from userinfo, not USE_ID_TOKEN

The login lands once authentik emits the email claim (the IdP fix); Grafana needs
no USE_ID_TOKEN toggle, and dropping it also avoids a *_TOKEN false-positive in
the literal-secret seam. Correct the two SSO notes accordingly.

serverAppConfigs-docs/Infrastructure/Authentik Outpost Reference.md

@@ -119,13 +119,13 @@ implementation diverges from upstream in ways that bit us; all verified live:
   `return {"email": user.email, "email_verified": True}`. With no email, Grafana
   v13 falls back to GET `<api_url>/emails`; authentik 404s it → "Login failed:
   InternalError".
-- **Claims ride in the id_token.** `include_claims_in_id_token` is on for this
-  provider and Grafana reads identity from it (`USE_ID_TOKEN=true`).
+- **Grafana reads identity from the standard userinfo endpoint** (`API_URL` with
+  no `?api=1`); no `USE_ID_TOKEN` is needed once the `email` claim exists.
 - **Net (2026-10-20):** the evaluator is fine; email/profile claims reach RP
-  clients. Both IdP fixes are idempotent in `scripts/authentik-grafana-sso-fix.sh`
- (re-run after an ak-shell re-creation of the provider or a blueprint import,
-  which revert them). Grafana's half + the verified outcome (Viewer,
-  `login = <sub hex>`, email present) are in [[Grafana]].
+  clients. Both IdP fixes are idempotent in
+  `scripts/authentik-grafana-sso-fix.sh` (re-run after an ak-shell re-creation of
+  the provider or a blueprint import, which revert them). Grafana's half plus the
+  verified outcome (Viewer, `login = <sub hex>`, email present) are in [[Grafana]].
 
 ## LDAP provider objects (provisioned via `ak shell` ORM)
 

serverAppConfigs-docs/Infrastructure/Grafana.md

@@ -75,11 +75,11 @@ Grafana responds on `/api/health` with 200 and `"database":"ok"`; measured 2026-
   an ak-shell re-creation of the provider or a blueprint import, both of which
   revert it silently). The Grafana half is the unit's own env (`grafana.container`):
   `SCOPES="openid email profile"` (a GitLab-style `user:email` scope crashes the
-  authorize view), `USE_ID_TOKEN=true` + no `?api=1` (Grafana v13 otherwise GETs
-  `<api_url>/emails`, which authentik 404s and the login dies with "Login failed:
-  InternalError"), attribute paths `email`/`sub`/`preferred_username`, and
-  `ALLOW_SIGN_UP=true` — safe because the guard fronts every request, so the
-  callback is unreachable to unauthenticated traffic.
+  authorize view), the standard userinfo `API_URL` with **no `?api=1`**, the
+  attribute paths `email`/`sub`/`preferred_username`, and `ALLOW_SIGN_UP=true`
+  (safe: the guard fronts the callback). Grafana v13 only GETs `<api_url>/emails`
+  when the token carries no `email` claim — so it is the email claim itself (an
+  IdP fix, above) that makes the login land, not any Grafana toggle.
 - **What a new login becomes:** a Viewer in org 1 (`ALLOW_ASSIGN_ORG=true`,
   `ORG_ID=1`, no role-attribute mapping), with `login = <sub hex>` but the real
   `email`. The local admin account stays the only Admin. The landing that the