feat: Nutzerverwaltung für Ebene 4 (Mandanten-Verwaltung)

Ein admin kann jetzt weitere Logins im eigenen Mandanten anlegen
(GET /verwaltung/nutzer, GET/POST /verwaltung/nutzer/neu) mit einer
der vier Mandanten-Rollen — betreiber bleibt Ebene 5 vorbehalten und
kann von keinem Mandanten-Admin vergeben werden. Schließt die Lücke,
dass die Fachebene (verantwortlicher/pruefer) bisher nur per
manuellem SQL-Insert erreichbar war, weil die Firma-Registrierung
ausschließlich einen admin-Nutzer erzeugt.

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

CLAUDE.md

@@ -72,6 +72,21 @@ ist der Nachfolger dessen, was früher (vor dem Produktwechsel)
 Rechte werden **als Prüfung an jeder Aktion** durchgesetzt (Middleware
 je Handler), nicht als grob unterschiedene Seitenbereiche.
 
+**Ebene 4 — Nutzerverwaltung ist umgesetzt** (`internal/web/admin_handlers.go`,
+Middleware `requireAdmin`): `GET /verwaltung/nutzer` listet alle Logins
+des eigenen Mandanten, `GET/POST /verwaltung/nutzer/neu` legt einen
+weiteren Login mit einer der vier Mandanten-Rollen an (`mitarbeiter`,
+`verantwortlicher`, `pruefer`, `admin` — `betreiber` kann kein
+Mandanten-Admin vergeben, das ist Ebene 5). Es gibt noch **keine**
+Einladungsmail — der Admin setzt das Initialpasswort direkt im
+Formular und gibt es auf einem anderen Weg weiter (konsistent mit dem
+Onboarding-Stand unten: Einladungslink/CSV-Import/SSO sind noch nicht
+gebaut). Das schließt die Lücke, dass Ebene 3 (Fachebene) bisher nur
+über einen manuellen SQL-Insert nutzbar war, weil die Firma-
+Registrierung ausschließlich einen `admin`-Nutzer erzeugt. Abteilungen-
+Verwaltung, Anmeldeverfahren, eigene Werkzeug-Freigaben/-Sperrungen und
+Rechnungsdaten (Ebene 4 laut Tabelle oben) sind weiterhin nicht gebaut.
+
 **Mandantenfähigkeit:** jede Tabelle trägt `account_id`. Aktuell wird
 Isolation in der Anwendungsschicht erzwungen (Handler vergleichen
 `AccountID` gegen den angemeldeten Account, wie bisher) — die