IAM-16: login-account-dienst-starten

- cmd/account-api: tenant-gescopter Login/Account-Dienst, setzt die
  fertigen IAM-08-Handler zusammen (auth, authtoken, totp) - Login ueber
  totp.Handler.Login (deckt 2FA optional mit ab), Passwort-Reset ueber
  authtoken.LogNotifier (IAM-08s eigene Uebergangsloesung)
- reines Wiring, kein Diff an internal/auth|authtoken|totp|user
  (verifiziert)
- real deployed auf 131, end-zu-ende per curl: falsches Passwort->401,
  korrektes Passwort->echte Session-Cookie, geschuetzter Endpunkt mit
  Cookie->200 (echte Nutzerdaten), ohne Cookie->401
- Migrationen (users/totp/password_tokens) real auf tenant_acme
  angewendet, reale Grant-Luecke behoben und verifiziert
- RBAC-05s Board-dependsOn um IAM-16 ergaenzt (RBAC-05 braucht dieselbe
  Auth-Middleware, bei Sichtpruefung festgestellt)

Pruefungen siehe docs/IAM-16-PRUEFPROTOKOLL.md

docs/IAM-16-PRUEFPROTOKOLL.md

@@ -0,0 +1,78 @@
+# IAM-16 – Prüfprotokoll: Login/Account-Dienst starten (IAM-08 als laufender Dienst)
+
+Voraussetzung IAM-08 – bereits Fertig, hier UNVERÄNDERT.
+
+## Bedeutung über IAM-08 hinaus
+
+IAM-16 ist nicht nur die Voraussetzung für die IAM-08-eigenen Prüfungen,
+sondern die grundlegende Session-/Auth-Infrastruktur für JEDE
+Auth-geschützte Core-GUI (`auth.RequireAuth`/`auth.ClaimsFromContext`).
+Bei der RBAC-05-Sichtprüfung wurde festgestellt, dass
+`internal/rbac.Handler.ListRoles` genau diese Middleware voraussetzt —
+RBAC-05s Board-`dependsOn` wurde entsprechend um IAM-16 ergänzt.
+
+## Reines Wiring, keine neue Logik
+
+`git diff --stat internal/auth/ internal/authtoken/ internal/totp/ internal/user/`
+liefert KEINEN Diff gegenüber dem IAM-08-Stand. `cmd/account-api/main.go`
+setzt ausschließlich bestehende Konstruktoren zusammen (u. a.
+`totp.Handler.Login` als DER EINE Login-Endpunkt, der optional 2FA
+mitprüft — bereits so von IAM-08 dokumentiert). Passwort-Reset nutzt
+`authtoken.LogNotifier{}` — ebenfalls bereits von IAM-08 als
+Übergangslösung bereitgestellt (Versand über CFG-02/CFG-05 ist explizit
+ein späterer Austausch, kein IAM-16-Thema).
+
+## Umsetzung
+
+- `cmd/account-api/main.go` – tenant-gescopter (Modell C) Login/Account-
+  Dienst: `POST /auth/login` (2FA-fähig), `POST /auth/logout`,
+  `POST /auth/password-reset/{request,complete}`, `GET /account/me`,
+  `POST /account/change-password`, `GET/POST /auth/totp/*` (Status/
+  Setup) — letztere drei hinter `auth.RequireAuth`.
+- `deploy/systemd/nexarch-account-api.service.tmpl`.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-account-api.service` aktiv, `Restart=on-failure` |
+| 2 | Realer Login-Versuch (korrektes Passwort) liefert eine gültige Session, falsches Passwort wird abgelehnt | **bestanden** – real per `curl`: falsches Passwort → 401 (`invalid_credentials`); korrektes Passwort → 200 mit echtem, signiertem `nexarch_session`-JWT-Cookie (`HttpOnly`, `Secure`, `SameSite=Strict`); anschließend `GET /account/me` MIT Cookie → 200 mit den echten Nutzerdaten, OHNE Cookie → 401 |
+| 3 | Code-Review: keine Änderung an internal/auth/, internal/authtoken/, internal/totp/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: alle vier Pakete unverändert gegenüber IAM-08 |
+
+## Echte Verdrahtung auf 192.168.1.131
+
+- `account-api` gebaut nach `/opt/nexarch-core/bin/`,
+  `/etc/nexarch/account-api.env` (0600), `nexarch-account-api.service`
+  installiert/aktiviert.
+- Migrationen `0001_users`, `0002_users_password`, `0003_totp`,
+  `0003_password_tokens` real auf `tenant_acme` angewendet (fehlten
+  bisher dort) — `nexarch_core` hatte zusätzlich keine
+  CREATE-Berechtigung auf `tenant_acme`, Migrationen daher als
+  `postgres` ausgeführt (Betriebs-Erkenntnis, kein IAM-16-Defekt: DDL
+  läuft grundsätzlich privilegiert, DML über die Anwendungsrolle).
+- Reale Grant-Lücke gefunden und behoben (gleiches Muster wie zuvor):
+  `nexarch_core` hatte keine Rechte auf `users`, `totp_credentials`,
+  `totp_recovery_codes`, `totp_policy`, `password_tokens` — `GRANT`
+  nachgezogen und über `information_schema.role_table_grants`
+  verifiziert.
+- End-zu-Ende-Beweis: echter Testnutzer angelegt (`bcrypt`-Hash über
+  `auth.HashPassword`), Login-Fehlversuch und -Erfolg, geschützter
+  Endpunkt mit/ohne Cookie — alle Testdaten anschließend entfernt.
+
+## Build/Test-Ergebnis (192.168.1.131)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./cmd/account-api/...  -> 0 issues
+```
+
+Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go, die
+eigentliche Logik ist bereits durch IAM-08s eigene Tests abgedeckt).
+
+## Gesamtergebnis
+
+**Bestanden.** IAM-08 ist jetzt ein real laufender, über systemd
+verwalteter Dienst — Voraussetzung für RBAC-05 und jede weitere
+Auth-geschützte Core-GUI. Board-`dependsOn` von RBAC-05 wurde vor
+dieser Umsetzung entsprechend korrigiert.