Benutzer bearbeiten (Name/E-Mail) + Kern-Einstellungen nur Superadmin

Nachschärfung der Benutzer-/Rollenverwaltung auf Basis des Feedbacks.

- Nutzer editierbar: Name & E-Mail (eindeutig je Mandant) je Nutzer in beiden
  Konsolen — updateTenantUser (Plattform) / updateUser (Tenant), inline-Formular
  in platform-tenant-users.tsx und tenant-users-manager.tsx. Rollen/Status/Reset
  bestanden bereits (browser-verifiziert: Name/E-Mail, Rollen, Deaktivieren, Reset).
- Kern-Einstellungen ausschließlich Superadmin: TISAX-/Schutzbedarf-Tiefe wandert
  in die Admin-Konsole (setTenantTisaxLevel, AL2/AL3 in /admin/[id]); aus den
  Tenant-Einstellungen entfernt (nur noch Read-only-Anzeige). updateTenantSettings
  fasst tisaxLevel/Schutzbedarf-Flags nicht mehr an. Module waren bereits Superadmin.
- Tenant-Einstellungen: „Benutzer & Rollen"-Bereich verlinkt und sichtbar
  (user:manage/role:manage) — Verwaltung unter /settings/users.

Browser-verifiziert: Admin-Konsole editiert Name/E-Mail/Rollen/Status/Passwort und
schaltet TISAX AL3; /settings zeigt Benutzer-Bereich + TISAX read-only;
/settings/users listet Nutzer mit Editierfeldern. tsc + lint + build + Guard grün.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/HANDOVER-DEV.md

@@ -177,6 +177,8 @@ Aufbauend auf dem Fundament wurden mehrere Härtungspakete umgesetzt (feingranul
   - Mandanten-Admin intern: `src/server/actions/tenant-users.ts` + `components/tenant-users-manager.tsx`/`role-manager.tsx`, Seite `/settings/users` (nur `user:manage`/`role:manage`). Benutzer-CRUD **und** Rollen-CRUD (eigene Rollen + Permissions; Standardrollen schreibgeschützt/klonbar). Strikt `dbForTenant(session)` → kein Cross-Tenant. **Lockout-Schutz** für den letzten aktiven Mandanten-Admin.
   - **Force-Change:** neue Nutzer starten mit `mustChangePassword=true`; das `(app)`-Layout leitet autoritativ (DB) auf `/change-password` und sperrt deaktivierte Konten. Passwort-Policy: `src/lib/password-policy.ts` (Validierung, client-safe) + `src/server/password.ts` (Argon2id-Hash + Generator); Quelle `TenantSettings.securityPolicy.password`.
   - **Nutzer-MFA optional:** Tenant-Login (`auth.ts`) verlangt TOTP nur bei eingerichteter MFA; Self-Service unter `/account`. `role:manage` ist neu im RBAC-Katalog (Mandanten-Admin).
+  - **Bearbeiten:** je Nutzer sind **Name & E-Mail** (E-Mail eindeutig je Mandant), Rollen, Aktiv/Deaktiviert und Passwort-Reset editierbar — in beiden Konsolen.
+- **Zuständigkeit Einstellungen (Superadmin vs. Tenant-Admin):** **Kern-Einstellungen** (aktive Module, TISAX-/Schutzbedarf-**Tiefe**, Richtlinienpaket) steuert ausschließlich der **Superadmin** in der Admin-Konsole (`/admin/[id]`, u. a. `setTenantTisaxLevel`). Der **Tenant-Admin** pflegt in `/settings` nur seinen Bereich (Stammdaten/Branding → ISMS-Variablen) + Benutzer/Rollen; die TISAX-Tiefe ist dort nur noch als Read-only-Anzeige.
 - **Zukunftssicher:** `createTenantUser`/`createUser` kapseln die Aktivierung über Initial-/Einmal-Passwort — der spätere **E-Mail-Einladungs-Flow (Paket 4)** lässt sich als alternative Aktivierung (Token statt Passwort) einhängen, ohne die UI umzubauen.
 
 ## 11. Nächste sinnvolle Aufgaben (Einstiegspunkte)