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/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