Admin-Konsole & Mandantenverwaltung (Phase 1)

Plattform-Admin-Konsole (Superadmin) + Kunden-Einstellungsbereich:

- Datenmodell: TenantSettings (Quelle der ISMS-Template-Variablen), TenantModule
  (Feature-Toggles je Mandant), Tenant += short/sector, TenantStatus += ARCHIVED,
  AuditLog += scope (tenant|platform); RLS für die neuen Tenant-Tabellen.
- Wiederverwendbare Provisionierung (server/provision.ts): Rollen+Permissions,
  erster Admin-User, Einstellungen, alle Module, optional Richtlinienpaket-Seed +
  TISAX-Default; idempotent + Audit (§3.7). syncPolicyVariablesFromSettings mappt
  Stammdaten → ISMS-Variablen (ORG_NAME, ISMS_SCOPE, ROLE_* …).
- Admin-Konsole /admin (Guard isPlatformAdmin): Mandantenliste, „Neuer Kunde"
  (anlegen + provisionieren), Detailseite mit Modul-Toggles, Lebenszyklus
  (aktiv/gesperrt/archiviert), Nutzerliste. Aktionen im Plattform-Audit-Log.
- Kunden-Einstellungen /settings (Guard tenant:manage): Unternehmensdaten,
  verantwortliche Rollen, Branding/Regionales, TISAX-Level — Stammdaten speisen
  die ISMS-Variablen (eine Pflegestelle). Modul-Übersicht.
- Modul-Gating der Navigation (deaktivierte Module ausgeblendet); Login bereits
  für gesperrte/archivierte Mandanten blockiert (auth.authorize).
- Seed: Demo-Mandant mit Einstellungen, 12 aktiven Modulen; admin@demo.example
  = Superadmin.

Verifiziert: tsc/lint/build grün; Seed rollt Einstellungen/Module/Superadmin aus.
(Browser-Verifikation diese Sitzung nicht möglich — Preview-Tools getrennt.)

Offen (Phase 2): separater Superadmin-Store + eigener Login + MFA-Pflicht;
Impersonation (zeitlich begrenzt, protokolliert); Plan/Limits; Logo-Upload/
Objektspeicher; SMTP/Benachrichtigungen; per-Route-Modul-Enforcement (serverseitig);
Datenexport/Löschung/Retention (DSGVO); SSO.

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

src/server/db.ts

@@ -28,6 +28,8 @@ const TENANT_MODELS = new Set<string>([
   "User",
   "Role",
   "AuditLog",
+  "TenantSettings",
+  "TenantModule",
   "Asset",
   "AssetRelation",
   "Process",