docs: document Gitea OIDC CustomURLMapping fix in infrastructure.org

The OIDC auto-discovery uses internal Docker hostnames. The browser
can't resolve authentik:9000, so CustomURLMapping.auth_url must be
set to the public URL in Gitea's database. This change is manual
(not tangled), so document the SQL and rationale.

infrastructure.org

@@ -869,6 +869,27 @@ the app can authenticate directly via a browser-based login flow.
   Users log in via "Sign in with Authentik" button on the Gitea login page.
   Existing user accounts are linked by username match.
 
+  *Critical manual fix:* The OIDC auto-discovery URL uses the internal
+  Docker hostname (=http://authentik:9000/application/o/gitea-oidc/...=).
+  This is correct for Gitea's backend (token/userinfo endpoints) but
+  Authentik's discovery response returns =http://authentik:9000/...= for
+  =authorization_endpoint=, which the browser cannot resolve.
+
+  To fix: add =CustomURLMapping.auth_url= in Gitea's =login_source= table
+  so the redirect uses the public URL:
+
+  #+BEGIN_SRC sql :eval never
+  UPDATE login_source SET cfg = json_set(cfg, '$.CustomURLMapping',
+    json_object('auth_url', 'https://auth.gharbeia.net/application/o/gitea-oidc/authorize'))
+  WHERE id = 1;
+  #+END_SRC
+
+  This change is in Gitea's SQLite database at =/data/gitea/gitea.db=,
+  not managed by tangling. It survives container rebuilds because the
+  database volume persists. To verify: =SELECT json_extract(cfg,
+  '$.CustomURLMapping') FROM login_source WHERE id=1;= should show the
+  mapping. Restart Gitea after updating (=docker restart gitea=).
+
 - Jellyfin: uses the SSO-Auth plugin (v4.0.0.4) with an Authentik OIDC
   provider (client_id = =jellyfin-sso=). The plugin does a two-step flow:
   1. OIDC callback returns an HTML page with JavaScript + authorization state