Remove unverified LDAP workaround claim from SSO docs

The source material says header-based forward-auth is 'the viable
path instead, if SSO is wanted for an app like this' - conditional
contingency guidance for a scenario that may not have actually come
up, not a description of something built and running. Presenting it
as live, deployed behavior in both docs/sso-and-identity.md and the
README was a real accuracy error. Removed from both; the doc still
covers what's actually confirmed (Authentik, dual-zone registration,
native OIDC vs. proxy forward-auth split, least-privilege Git access).

docs/sso-and-identity.md

@@ -34,11 +34,6 @@ This split matters more than it looks: the browser-facing zone enforces mutual T
 
 Every app-specific setting beyond this shape (token lifetime, scopes, flow type) is deliberately **not** generalized across apps — each app's own OIDC documentation gets read fresh rather than copying another app's provider config, since the details genuinely differ per vendor and copying blind is how subtle auth bugs get introduced.
 
-## A real platform limitation, worked around rather than ignored
-
-> [!WARNING]
-> Authentik's own LDAP outpost **hides superuser accounts from LDAP directory search** — so any app requiring a search-then-bind LDAP flow (a media server's user-management plugin, for instance) can never authenticate the fleet's primary superuser account through LDAP, full stop. Two workarounds were on the table: create a second, non-admin account just for LDAP-dependent apps, or demote the primary account from superuser entirely. Both were rejected — a second account fragments identity across the fleet in a way that undermines the whole point of centralized SSO, and demoting the primary account breaks unrelated admin workflows that depend on superuser rights. **Header-based forward-auth is used instead** for any app in this situation: Authentik's proxy layer authenticates the user and passes identity via HTTP headers, sidestepping the LDAP search-then-bind requirement entirely rather than working around Authentik's own limitation inside LDAP itself.
-
 ## Git access: least privilege, not the admin account
 
 ```mermaid