feat: Firmen-CRUD für den Betreiber (anlegen, umbenennen)

Schließt eine echte Lücke: der Betreiber-Bereich konnte Accounts
bisher nur lesend anzeigen, eine neue Firma entstand ausschließlich
über die öffentliche Selbstregistrierung. GET/POST
/betreiber/accounts/neu legt jetzt eine Firma samt erstem admin-Login
direkt vom Betreiber aus an (z. B. für vertriebsunterstütztes
Onboarding oder Testkonten) — erzeugt einen audit_log-Eintrag. POST
/betreiber/accounts/{id}/umbenennen korrigiert den Firmennamen
(store.UpdateAccount). Bewusst kein Löschen: ein Hard-Delete würde
gegen die Fremdschlüssel aus antrag/app_user/audit_log laufen und
Historie zerstören — dasselbe Prinzip wie bei Nutzern (deaktivieren
statt löschen), ein Sperren/Deaktivieren für Accounts fehlt aber noch
und hängt an der noch nicht getroffenen Abrechnungsarchitektur.

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

CLAUDE.md

@@ -129,15 +129,27 @@ 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.
 
+**Firmen-CRUD für den Betreiber ist umgesetzt:** `GET/POST
+/betreiber/accounts/neu` legt eine Firma samt erstem `admin`-Login an
+(dasselbe Ergebnis wie die öffentliche Registrierung, nur vom Betreiber
+ausgelöst — z. B. für vertriebsunterstütztes Onboarding oder Testkonten),
+`POST /betreiber/accounts/{id}/umbenennen` korrigiert den Firmennamen
+(`store.UpdateAccount`). Jede Firmenanlage erzeugt einen
+`audit_log`-Eintrag. Bewusst **kein** Löschen — ein Hard-Delete würde
+gegen die Fremdschlüssel aus `antrag`/`app_user`/`audit_log` laufen und
+Historie zerstören (dasselbe Muster wie bei Nutzern: deaktivieren statt
+löschen, aber ein Sperren/Deaktivieren-Zustand für Accounts existiert
+noch nicht, siehe unten).
+
 **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).
+Zugangsdaten), Sperren/Deaktivieren eines Accounts durch den Betreiber
+(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