feat(auth): Forward-Auth via JWT-Cookie (YunoHost yunohost.portal)

Discovery zeigte: YunoHost reicht den Usernamen nicht als Header durch, sondern im
signierten Cookie "yunohost.portal" (JWT, Claim "user"). Die Forward-Auth liest jetzt
die Identitaet aus Header ODER Cookie - nur von der Proxy-Quell-IP akzeptiert.
HS256-Signaturpruefung optional via TRUSTED_AUTH_JWT_SECRET (stdlib hmac, kein Dep).

- config: trusted_auth_cookie / _cookie_claim / _jwt_secret
- nginx-Vorlage + deploy/README: keine Identitaets-Header-Zeile mehr noetig; SSO-Schutz
  der Subdomain ist Pflicht (sonst Spoofing)
- Tests: Cookie-Extraktion, Signaturpruefung, Proxy-IP-Trust

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/va.linix.de.nginx.conf

@@ -31,12 +31,8 @@ location / {
     proxy_read_timeout 3600s;
     proxy_send_timeout 3600s;
 
-    # Identitaets-Header: SSOwat setzt die Nutzeridentitaet. Nach der Discovery
-    # (GET /api/admin/request-headers hinter dem SSO) den richtigen Namen hier
-    # FEST setzen und Client-Spoofing verwerfen. Beispiel, wenn SSO $remote_user
-    # bereitstellt (Name ggf. anpassen):
-    #
-    #   proxy_set_header X-Remote-User $remote_user;
-    #
-    # In der Gateway-Konfiguration dann:  TRUSTED_AUTH_HEADER=X-Remote-User
+    # Identitaet: KEIN eigener Header noetig. YunoHost liefert den Usernamen im
+    # Cookie "yunohost.portal" (JWT, Claim "user"); Cookies werden hier ohnehin
+    # durchgereicht. Das Gateway liest den Cookie (TRUSTED_AUTH_COOKIE=yunohost.portal).
+    # Wichtig: die Subdomain MUSS per SSO geschuetzt sein (sonst Identitaets-Spoofing).
 }