docs: add OIDC cross-zone redirect diagram to sso-and-identity.md

Sequence diagram showing the browser carries every hop itself -
Authentik and the app never talk directly - with only the OAuth
authorize/token exchange crossing from the browser-facing zone into
the service-to-service zone. Built to the public-repo diagram
conventions in CLAUDE.md (labelBackgroundColor + matching rich-text
span, off-line label positioning, line-color-matched labels, legend
instead of a color-explaining caption).

docs/sso-and-identity.md

@@ -53,6 +53,8 @@ For an app using native OIDC, the login always follows the same path:
 3. That exchange happens against Authentik's own address on the **service-to-service zone** — reachable from a browser for this one hop specifically, even though that zone doesn't get the mutual-TLS treatment the browser-facing zone does.
 4. On success, the browser lands back on the app, still on the browser-facing zone.
 
+![OIDC cross-zone redirect: the browser carries every hop itself — Authentik and the app never talk to each other directly — with only the OAuth authorize/token exchange ever crossing from the browser-facing zone into the service-to-service zone](../assets/sso-and-identity-oidc-cross-zone-redirect.svg)
+
 So an app's OIDC discovery/authority setting always points at the service-to-service zone, even though the app itself is normally reached on the browser-facing zone — the two zones are defined in [`docs/dns-naming.md`](dns-naming.md). This is confirmed against one real app's actual login flow, not assumed to hold for every app without checking. Every other app-specific setting (token lifetime, scopes, flow type) doesn't generalize the same way — each app's own OIDC documentation gets read fresh rather than copying another app's provider config, since those details genuinely differ per vendor.
 
 > [!NOTE]