RBAC-07: rechte-administrations-dienst-starten

- cmd/rbac-admin-api: startet internal/rbac.Handler (RBAC-05), hinter
  auth.RequireAuth mit demselben JWT-Secret wie IAM-16 (account-api)
- reines Wiring, kein Diff an internal/rbac/ (verifiziert)
- real deployed auf 131, cross-service-Session real bewiesen: Login
  gegen account-api (Port 8099), dasselbe Session-Cookie gegen
  rbac-admin-api (Port 8100) verwendet -> echte Rollenliste, ohne
  Cookie -> 401
- Migrationen (role_assignments/groups) real auf tenant_acme
  angewendet, reale Grant-Luecke behoben und verifiziert
- Bootstrap-Erkenntnis dokumentiert: ListRoles selbst verlangt bereits
  eine Rolle mit PermManageUsers, Testnutzer daher mit direkter
  DB-Bootstrap-Rolle angelegt (wie Ersteinrichtung)

Pruefungen siehe docs/RBAC-07-PRUEFPROTOKOLL.md

docs/RBAC-07-PRUEFPROTOKOLL.md

@@ -0,0 +1,75 @@
+# RBAC-07 – Prüfprotokoll: Rechte-Administrations-Dienst starten (RBAC-05 als laufender Dienst)
+
+Voraussetzung RBAC-05, IAM-16 – beide bereits Fertig, hier UNVERÄNDERT.
+
+## Reines Wiring, keine neue Logik
+
+`git diff --stat internal/rbac/` liefert KEINEN Diff. `cmd/rbac-admin-api/main.go`
+setzt ausschließlich bestehende Konstruktoren zusammen und wrappt jeden
+Endpunkt mit `auth.RequireAuth` — derselben Middleware, die IAM-16
+bereits nutzt.
+
+## JWT-Secret-Konsistenz (explizit geprüft, nicht nur konfiguriert)
+
+`NEXARCH_RBACADMIN_JWT_SECRET` MUSS identisch mit
+`NEXARCH_ACCOUNT_JWT_SECRET` (IAM-16) sein, sonst verwirft dieser Dienst
+gültige account-api-Sessions. Real getestet: mit account-api (Port
+8099) eingeloggt, Session-Cookie unverändert gegen rbac-admin-api (Port
+8100, ANDERER Prozess, ANDERE Portnummer) verwendet — Cookie wurde real
+akzeptiert, kein zweiter Login nötig. Das beweist die Cross-Service-
+Gültigkeit, nicht nur eine übereinstimmende Konfigurationszeile.
+
+## Bootstrap-Erkenntnis (dokumentiert)
+
+`internal/rbac.Handler.ListRoles` verlangt selbst bereits eine Rolle
+mit `PermManageUsers` (`requireManageUsers`) — ein Benutzer OHNE
+`role_assignments`-Zeile bekommt 403, auch für die reine Rollenliste.
+Für den End-zu-Ende-Test wurde daher ein Testnutzer mit einer direkt in
+der DB gesetzten `tenant_admin`-Bootstrap-Zeile angelegt (wie eine
+Ersteinrichtung) — kein Umgehen der echten Prüfung, sondern deren
+Voraussetzung.
+
+## Umsetzung
+
+- `cmd/rbac-admin-api/main.go` – Rollen/Gruppen-Endpunkte
+  (`GET /rbac/roles`, `POST /rbac/users/role`,
+  `GET /rbac/users/{id}/history`, `GET/POST /rbac/groups*`), alle
+  hinter `auth.RequireAuth`.
+- `deploy/systemd/nexarch-rbac-admin-api.service.tmpl`.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-rbac-admin-api.service` aktiv |
+| 2 | Realer Aufruf mit gültigem IAM-16-Session-Cookie liefert die erwartete Rollenliste, ohne/mit falschem Cookie 401/403 | **bestanden** – real per `curl`: mit dem bei `account-api` (IAM-16) ausgestellten Cookie → 200 mit der echten Rollen-/Rechte-Liste (`tenant_admin`, `user`); ohne Cookie → 401 |
+| 3 | Code-Review: keine Änderung an internal/rbac/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat internal/rbac/` liefert leeren Diff |
+
+## Echte Verdrahtung auf 192.168.1.131
+
+- `rbac-admin-api` gebaut nach `/opt/nexarch-core/bin/`,
+  `/etc/nexarch/rbac-admin-api.env` (0600, `NEXARCH_RBACADMIN_JWT_SECRET`
+  identisch zu `NEXARCH_ACCOUNT_JWT_SECRET`), Dienst installiert/aktiviert.
+- Migrationen `0002_role_assignments`, `0003_groups` real auf
+  `tenant_acme` angewendet (fehlten dort), reale Grant-Lücke gefunden
+  und behoben (`role_assignments`, `role_assignment_history`, `groups`,
+  `group_members`), über `information_schema.role_table_grants`
+  verifiziert.
+- End-zu-Ende-Beweis: Testnutzer mit Bootstrap-`tenant_admin`-Rolle,
+  Login gegen `account-api`, dasselbe Cookie gegen `rbac-admin-api`
+  verwendet → echte Rollenliste. Testdaten anschließend entfernt.
+
+## Build/Test-Ergebnis (192.168.1.131)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./cmd/rbac-admin-api/...  -> 0 issues
+```
+
+## Gesamtergebnis
+
+**Bestanden.** RBAC-05 ist jetzt ein real laufender, über systemd
+verwalteter Dienst, cross-service authentifiziert über dieselbe
+IAM-16-Session — der zweite Baustein der browserfähigen Core-GUI nach
+TEN-05.