feat: Ebene 4 vollständig steuerbar machen — Abteilungen, Werkzeug-Sperrungen, Nutzer-Deaktivierung

Deklarix soll ein buchbarer Service werden — dafür muss jede Entität im
Datenmodell über das Frontend steuerbar sein, nicht nur einsehbar.
Schließt drei konkrete Lücken:

- Abteilungen (GET /verwaltung/abteilungen, anlegen/löschen) — ohne
  diese Seite blieb die Abteilung-Auswahl im Antrag-Fragebogen leer
  und unbenutzbar, das war ein Funktionsdefizit, kein Komfortfehler.
- Eigene Werkzeug-Sperrungen (GET /verwaltung/werkzeuge) — ein Mandant
  kann einen zentralen Katalogeintrag jetzt für sich sperren/entsperren,
  ohne den zentralen Katalog selbst zu verändern.
- Nutzer-Deaktivierung (POST /verwaltung/nutzer/{id}/deaktivieren bzw.
  .../aktivieren, neue Spalte app_user.active, Migration 0012). Nutzer
  werden nicht gelöscht (Fremdschlüssel auf antrag/entscheidung/
  audit_log würden das verhindern und die Historie zerstören) —
  deaktivierte Logins können sich nicht mehr anmelden und verlieren
  eine laufende Sitzung sofort. Ein Admin kann sich nicht selbst
  deaktivieren.

Zusätzlich: store.ListAktiveGenehmigungenForAccount als Grundlage für
die Wiedervorlage (Schritt 7, Web-Layer folgt).

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

CLAUDE.md

@@ -72,20 +72,46 @@ 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.
+**Ebene 4 ist inzwischen zu großen Teilen umgesetzt** (Anspruch: alles,
+was im Datenmodell existiert, muss über das Frontend steuerbar sein,
+nicht nur einsehbar — Deklarix soll ein buchbarer Service werden, ein
+reiner Anzeige-Screen reicht nicht):
+
+- **Nutzerverwaltung** (`internal/web/admin_handlers.go`, Middleware
+  `requireAdmin`): `GET /verwaltung/nutzer` listet alle Logins des
+  eigenen Mandanten mit Status (aktiv/deaktiviert), `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. Nutzer werden **nicht gelöscht**
+  (`app_user` wird von `antrag`/`entscheidung`/`audit_log` per Foreign
+  Key referenziert — ein Hard-Delete würde die Historie zerstören),
+  sondern über `POST /verwaltung/nutzer/{id}/deaktivieren` bzw.
+  `.../aktivieren` (de-)aktiviert (Spalte `app_user.active`, Migration
+  0012). Ein deaktivierter Login kann sich nicht mehr anmelden
+  (`handleLogin` prüft `Active` erst NACH der Passwortprüfung, um keine
+  Kontoexistenz zu verraten) und verliert eine bereits laufende Sitzung
+  sofort (`authenticate`-Middleware prüft `Active` bei jedem Request).
+  Ein Admin kann sich nicht selbst deaktivieren (Aussperr-Schutz).
+- **Abteilungen** (`GET /verwaltung/abteilungen`, anlegen + löschen):
+  reine Stammdaten für das Fragebogen-Feld "Abteilung" — ohne diese
+  Seite blieb die Abteilung-Auswahl im Fragebogen faktisch leer und
+  unbenutzbar, das war kein Komfort-, sondern ein Funktionsdefizit.
+- **Eigene Werkzeug-Sperrungen** (`internal/web/mandant_werkzeug_handlers.go`,
+  `GET /verwaltung/werkzeuge`): ein Mandant kann einen zentralen
+  Katalogeintrag für sich sperren/entsperren (`werkzeug_sperre`), ohne
+  den zentralen Katalog selbst zu verändern — das bleibt Sache der
+  Plattform (Ebene 5, `betreiber_werkzeug_handlers.go`).
+
+**Weiterhin nicht gebaut:** Anmeldeverfahren-Konfiguration, eigene
+Werkzeug-EINTRÄGE eines Mandanten (nur Sperrungen zentraler Einträge
+sind umgesetzt, `account_id`-gesetzte eigene Katalogeinträge fehlen
+noch), 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).
 
 **Mandantenfähigkeit:** jede Tabelle trägt `account_id`. Aktuell wird
 Isolation in der Anwendungsschicht erzwungen (Handler vergleichen