feat: MFA (TOTP) und Self-Service-Profilseite

Benutzer koennen jetzt selbst Zwei-Faktor-Authentifizierung einrichten
und ihr Profil verwalten (Name, E-Mail, Passwort, Profilbild).

Backend:
- Neues MfaModule (src/auth/mfa/): AES-256-GCM-verschluesselte
  TOTP-Secrets (otplib), QR-Code-Erzeugung, kurzlebige Setup-/
  Challenge-JWTs fuer den 2-Schritt-Login-Flow
- Neues ProfileModule (src/profile/): PATCH /profile,
  POST /profile/password, POST/DELETE/GET /profile/avatar,
  POST /profile/mfa/enroll(/confirm), POST /profile/mfa/disable -
  alle self-scoped ueber actor.id, ohne @RequirePermission (siehe
  ALLOWLIST in authorization-coverage.e2e-spec.ts)
- AuthService.login() zweistufig: bei aktivem MFA erst
  { mfaRequired, mfaToken } statt Tokens, neuer Endpunkt
  POST /auth/mfa/verify schliesst den Flow ab
- Admin-Recovery: POST /users/:id/mfa/reset (users:update) fuer
  verlorene MFA-Geraete, da es keinen E-Mail-Reset-Flow gibt

Frontend:
- Login-Seite mit zweitem Schritt fuer den TOTP-Code
- Neue Profilseite (/profile, ausserhalb des admin-only
  Settings-Bereichs): Profilbild, Name/E-Mail, Passwort, MFA-Ein-/
  Ausrichtung mit QR-Code-Dialog
- Header zeigt jetzt Avatar mit Dropdown (Profil/Abmelden) statt
  nur E-Mail-Text
- Admin-Users-Tabelle zeigt MFA-Status + Reset-Button

Haertung nach Security-Review (Backend/Frontend-Diff, kein CRITICAL,
mehrere MEDIUM behoben):
- Access-Token wird bei Passwortwechsel sofort ungueltig
  (User.passwordChangedAt + JWT-iat-Vergleich in
  PermissionResolverService.isTokenValid, vorher isUserActive) statt
  erst nach bis zu 15 Minuten
- E-Mail-Aenderung verlangt jetzt aktuelles Passwort
- POST /profile/password und /profile/mfa/disable haben jetzt das
  gleiche strikte Throttling wie Login (SENSITIVE_ACTION_THROTTLE)
- Kein stiller leerer Verschluesselungs-Key-Fallback mehr (wirft
  jetzt explizit)

Bewusst zurueckgestellt (dokumentiert, kein aktiver Exploit-Pfad):
dedizierter Verschluesselungs-Key fuer MFA-Secrets statt
JWT_ACCESS_SECRET-Ableitung, dedizierte users:mfa-reset-Permission
statt users:update, separate JWT-Secrets pro Token-Zweck.

Verifiziert: tsc/eslint clean, 297/297 Backend- + 31/31
Frontend-Unit-Tests, Build clean auf beiden Projekten. e2e weiterhin
durch bekanntes WSL2/Postgres-Problem blockiert. Unabhaengiges
Security- und Code-Quality-Review durchgefuehrt (0 CRITICAL, 0 HIGH).

ApiCore-Backend/prisma/migrations/20260826213033_add_mfa_and_avatar/migration.sql

@@ -0,0 +1,8 @@
+-- AlterEnum
+ALTER TYPE "AuditAction" ADD VALUE 'MFA_ENABLED';
+ALTER TYPE "AuditAction" ADD VALUE 'MFA_DISABLED';
+
+-- AlterTable
+ALTER TABLE "User" ADD COLUMN     "mfaEnabled" BOOLEAN NOT NULL DEFAULT false,
+ADD COLUMN     "mfaSecret" TEXT,
+ADD COLUMN     "avatarPath" TEXT;

ApiCore-Backend/prisma/migrations/20260826221315_add_password_changed_at/migration.sql

@@ -0,0 +1,2 @@
+-- AlterTable
+ALTER TABLE "User" ADD COLUMN "passwordChangedAt" TIMESTAMP(3);

ApiCore-Backend/prisma/schema.prisma

@@ -76,6 +76,18 @@ model User {
   updatedAt     DateTime   @updatedAt
   deactivatedAt DateTime?
 
+  // TOTP-Secret AES-256-GCM-verschluesselt gespeichert (siehe
+  // src/auth/mfa/mfa-crypto.util.ts), nie im Klartext in der DB.
+  mfaEnabled Boolean @default(false)
+  mfaSecret  String?
+  avatarPath String?
+
+  // Gesetzt bei jedem Passwortwechsel; JwtAuthGuard verwirft Access-Tokens,
+  // die vor diesem Zeitpunkt ausgestellt wurden (siehe
+  // PermissionResolverService.isTokenValid), damit ein gestohlener Token
+  // nach einer Passwortaenderung nicht bis zu 15 Minuten weiter funktioniert.
+  passwordChangedAt DateTime?
+
   refreshTokens RefreshToken[]
 
   inspections           Inspection[]
@@ -124,6 +136,8 @@ enum AuditAction {
   LOGIN_FAILED
   LOGOUT
   TOKEN_REFRESHED
+  MFA_ENABLED
+  MFA_DISABLED
 }
 
 model AuditLog {