fix: admin bekommt Fachebene-Rechte (Posteingang, Entscheiden, Register, Wiedervorlage)

Löst einen Blocker im Kernablauf: eine frisch registrierte Firma hat
nur einen admin-Login und konnte damit bislang keinen einzigen
eingereichten Antrag sehen oder entscheiden, weil requireFachebene nur
verantwortlicher/pruefer durchließ. Die Spezifikation will admin+
KI-Verantwortlicher ohnehin auf derselben Person (siehe CLAUDE.md,
Offene Punkte) — statt eines Datenmodell-Umbaus (roles-Array oder
zwei app_user-Zeilen pro Person) bekommt admin jetzt pragmatisch
dieselben Fachebene-Rechte wie verantwortlicher (hatEntscheidungsrecht
in fachebene_handlers.go). pruefer bleibt unverändert nur lesend.

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

CLAUDE.md

@@ -67,7 +67,10 @@ Mandanten-Verwaltung für den eigenen Account) und `betreiber` (Ebene 5,
 Plattform-Betrieb für Netcell-IT über alle Mandanten) sind nicht
 dasselbe, auch wenn beide "Admin"-artige Rechte haben — nur `betreiber`
 ist der Nachfolger dessen, was früher (vor dem Produktwechsel)
-`admin` hieß.
+`admin` hieß. **Praktische Umsetzung dieser Doppelrolle:** `admin`
+bekommt zusätzlich dieselben Fachebene-Rechte wie `verantwortlicher`
+(siehe `requireFachebene`/`hatEntscheidungsrecht`) — pragmatisch gelöst
+ohne Datenmodell-Umbau, siehe Offene Punkte weiter unten.
 
 Rechte werden **als Prüfung an jeder Aktion** durchgesetzt (Middleware
 je Handler), nicht als grob unterschiedene Seitenbereiche.
@@ -750,11 +753,20 @@ journalctl -u deklarix -f
   ist ein bewusst noch nicht getroffener Architektur-Entscheid —
   Aufwand und Zeitpunkt mit dem Nutzer klären, bevor mehr Tabellen
   entstehen, die sonst nachträglich migriert werden müssten.
-- **"Admin und KI-Verantwortlicher" beim Firma-Onboarding** — die
-  Spezifikation will, dass der erste Nutzer beide Rollen gleichzeitig
-  hat; `app_user.role` ist aktuell ein einzelner Wert. Muss geklärt
-  werden: zwei Rollen pro Nutzer zulassen (Datenmodell-Änderung) oder
-  zwei `app_user`-Zeilen für dieselbe Person?
+- ~~"Admin und KI-Verantwortlicher" beim Firma-Onboarding~~ — **pragmatisch
+  gelöst, kein Datenmodell-Umbau:** `app_user.role` bleibt ein einzelner
+  Wert (kein `roles`-Array, keine zwei `app_user`-Zeilen pro Person).
+  Stattdessen bekommt die Rolle `admin` in `requireFachebene` (Ebene 3)
+  dieselben Rechte wie `verantwortlicher` — sieht Posteingang/Register/
+  Wiedervorlage und darf entscheiden (`hatEntscheidungsrecht` in
+  `fachebene_handlers.go`). Grund: ohne das könnte eine frisch
+  registrierte Firma mit nur einem `admin`-Login keinen einzigen
+  eingereichten Antrag sehen oder bearbeiten — der Kernablauf wäre für
+  Einzelpersonen-/Kleinfirmen-Onboarding komplett blockiert. `pruefer`
+  bleibt unverändert nur lesend, ohne Entscheidungsrecht. Kompromiss statt
+  "sauberer" Lösung — falls künftig eine Firma admin und verantwortlicher
+  bewusst auf zwei verschiedene Personen verteilen will, funktioniert das
+  weiterhin unverändert (zwei separate Logins mit den jeweiligen Rollen).
 - **Zentraler Werkzeugkatalog muss noch befüllt werden** — die
   Ebene-5/Betreiber-UI zur Katalogpflege ist jetzt gebaut (`GET
   /betreiber/werkzeuge` Liste, `GET/POST /betreiber/werkzeuge/neu`