Auth: OIDC-Provider-Abstraktion vorbereiten

[jurei733]

Parent: #151

Ziel

Auth-Konfiguration wird so abstrahiert, dass perspektivisch andere OIDC-Provider als Keycloak moeglich sind.

Akzeptanzkriterien

• Keycloak-spezifische Annahmen sind identifiziert.
• Konfiguration trennt generische OIDC-Parameter von Keycloak-spezifischen Details.
• Bestehende Keycloak-Nutzung bleibt funktionsfaehig.
• Dokumentation beschreibt Grenzen der Abstraktion.

[jurei733]

Stand der Umsetzung nach Abgleich mit den Pull Requests:

• Die relevante aktuelle PR ist Feature/OIDC authenticate flow #448 ("Feature/OIDC authenticate flow"). Der ältere PR Feature/OIDC auth flow #412 ist geschlossen und nicht gemerged; Feature/OIDC authenticate flow #448 wirkt wie der weitergeführte Nachfolger.
• Feature/OIDC authenticate flow #448 setzt wesentliche Teile dieses Issues um: generischer OidcAuthService, OIDC/OAuth2-Konfiguration (OIDC_*, OAUTH2_*), Auth-Code-Flow mit PKCE, Backend-Callback/Token-Exchange, Frontend-Tokenhandling sowie OIDC-Dokumentation in EN/DE.
• Die bestehende Keycloak-Nutzung bleibt in Feature/OIDC authenticate flow #448 weiterhin abgebildet, inkl. Dev-/Realm-Konfiguration und Keycloak-spezifischer Infrastruktur.

Einschätzung: Das Issue ist inhaltlich weitgehend vorbereitet/umgesetzt, aber noch nicht abgeschlossen. #448 ist aktuell offen und laut GitHub nicht sauber mergebar (mergeStateStatus: DIRTY). Außerdem bleiben bewusst oder unbewusst noch Keycloak-Annahmen sichtbar, z. B. realm_access.roles, preferred_username, Keycloak-Dev-Setup/Theme sowie ein separater KeycloakAuthService.

Vorschlag für Abschluss von #570:

1. Feature/OIDC authenticate flow #448 rebasen bzw. Merge-Konflikte lösen.
2. Die verbleibenden Keycloak-Annahmen explizit als Grenzen der Abstraktion dokumentieren oder in Folgeissues auslagern.
3. Feature/OIDC authenticate flow #448 mit diesem Issue verknüpfen, damit der Umsetzungsstand nachvollziehbar ist.