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).

README.md

@@ -99,7 +99,7 @@ A certificate expiring is a slow problem measured in days. A missing application
 → [docs/secret-distribution.md](docs/secret-distribution.md)
 
 ### 🪪 SSO & Identity
-The identity provider's own LDAP layer flatly refuses to authenticate superuser accounts — a hard vendor limitation, not a bug to file a ticket against. The fix wasn't a workaround bolted onto LDAP; it was routing that one case through a completely different authentication path instead, one zone boundary away from where the app itself actually lives.
+Authentik, self-hosted, fronts single sign-on for every app in the fleet that supports it — a dozen-plus apps on native OIDC where the upstream software allows it, everything else behind proxy-based forward-auth so apps that were never built with SSO in mind still get it. Every app registers twice, once per reverse-proxy zone, because authentication always happens on the internal zone even when the app itself lives on the browser-facing one. Git automation follows the same least-privilege instinct: a scoped bot account with write access replaces routing CI through an admin identity, so a leaked automation credential is never an admin credential.
 → [docs/sso-and-identity.md](docs/sso-and-identity.md)
 
 ### 🧱 Firewall & Network Segmentation