feat: Support-Login — Betreiber kann sich als Kunden-Nutzer anmelden

Ebene 5 (Betreiber) kann sich jetzt auf der Account-Detailseite über
einen Button je Nutzer als dieser Kunden-Login anmelden, ohne dessen
Passwort zu kennen — für Support-Fälle, in denen der Betreiber
nachvollziehen muss, was ein Kunde sieht. Nicht für deaktivierte
Nutzer möglich. Neue Spalte session.impersonated_by_user_id (Migration
0014, store.CreateImpersonatedSession) hält fest, wer die Sitzung
ausgelöst hat — die Nav zeigt während der gesamten Sitzung einen
auffälligen Banner ("Support-Zugriff durch ..."), damit nie unklar
ist, im Kontext eines fremden Kontos zu handeln. Jede Nutzung erzeugt
einen audit_log-Eintrag. Die neue Sitzung ersetzt die eigene
Betreiber-Sitzung (kein Sitzungs-Stack) — nach der Nutzung meldet sich
der Betreiber mit den eigenen Zugangsdaten neu an.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -115,12 +115,29 @@ reiner Anzeige-Screen reicht nicht):
   — ein zentraler oder fremder Eintrag ist über diese Route nicht
   erreichbar (404).
 
-**Weiterhin nicht gebaut:** Anmeldeverfahren-Konfiguration, Rechnungsdaten/
-Abrechnung (kein Abo-System, bewusst "Nicht bauen v1"), Account-
-Verwaltung durch den Betreiber (Ebene 5 zeigt Accounts nur lesend an —
-Bearbeiten/Sperren hängt an der noch nicht getroffenen Abrechnungs-/
-Freischaltungs-Architektur, siehe Offene Punkte: `account.verified`
-wurde beim Produktwechsel sogar entfernt).
+**Support-Login (Ebene 5, `betreiber`) ist umgesetzt** — auf
+`GET /betreiber/accounts/{id}` kann sich der Betreiber über
+`POST .../nutzer/{userID}/anmelden-als` als ein aktiver Kunden-Nutzer
+anmelden, ohne dessen Passwort zu kennen (`handleBetreiberLoginAls` in
+`betreiber_handlers.go`, `store.CreateImpersonatedSession`, Migration
+0014). Nicht für deaktivierte Nutzer möglich. Die neue Sitzung ersetzt
+die eigene Betreiber-Sitzung (kein Sitzungs-Stack/"Zurück zum
+Betreiber" — der Betreiber meldet sich danach mit den eigenen
+Zugangsdaten neu an). Jede Nutzung erzeugt einen `audit_log`-Eintrag
+(Action `betreiber_login_als_nutzer`); während der gesamten Sitzung
+zeigt die Nav einen auffälligen Banner ("Support-Zugriff durch ...",
+siehe `currentImpersonator` in `middleware.go`), damit nie unklar ist,
+im Kontext eines fremden Kontos zu handeln.
+
+**Weiterhin nicht gebaut:** Anmeldeverfahren-Konfiguration, ein echtes
+Abo-System (Preismodell und Zahlungsanbieter mit dem Nutzer am
+2026-08-30 grundsätzlich geklärt — 3 €/Mitarbeiter/Monat, Mindestabnahme
+10 Mitarbeiter, 14 Tage Testphase, Stripe mit SEPA-Lastschrift — die
+eigentliche Umsetzung wartet noch auf einen Stripe-Account/Testmodus-
+Zugangsdaten), Account-Verwaltung durch den Betreiber jenseits des
+Support-Logins (Bearbeiten/Sperren eines Accounts selbst hängt weiter
+an der Abrechnungs-/Freischaltungs-Architektur, siehe Offene Punkte:
+`account.verified` wurde beim Produktwechsel sogar entfernt).
 
 **Mandantenfähigkeit:** jede Tabelle trägt `account_id`. Aktuell wird
 Isolation in der Anwendungsschicht erzwungen (Handler vergleichen