Audit-Pruefung: "manipuliert" von "Luecke" getrennt + Retention fuer Routine-Auth

Problem 1 (Deutbarkeit): verifyIntegrity warf zwei voellig unterschiedliche
Befunde in einen Topf und meldete beides als "N manipulierte Eintraege". Eine
harmlose Verkettungsluecke sah damit aus wie ein Angriff - die Meldung war im
Alltag nicht deutbar und dadurch wertlos, dasselbe Muster wie beim
Refresh-Rauschen.

Fix: Rueckgabe um tamperedEntries (Inhalt nachtraeglich veraendert, ernst) und
chainGaps (Verkettung unterbrochen durch parallele Schreibvorgaenge oder
geloeschte Zeilen, meist harmlos) erweitert. invalidEntries bleibt als Summe
erhalten. Controller formuliert die Meldung eindeutig, Frontend-API-Typ
nachgezogen.

Problem 2 (Aufbewahrung): Token-Refreshes landen seit der Entrauschung als
Authentication/LOW. Diese Kombination traf auf keine spezifische Regel und fiel
in die Auffangregel * mit 3650 Tagen - das Rauschen waere 10 Jahre aufbewahrt
worden, echte Logins nur 2. Fix: Regel Authentication/LOW mit 90 Tagen, als
idempotente Migration und im Seed.

Sensitivitaet steuert die Aufbewahrung und ist keine Alarmstufe - normale
Logins und Zugriffe auf Bankdaten/Ausweise bleiben bewusst CRITICAL, ein
Herabstufen wuerde still die Aufbewahrungsfrist verlaengern.

Verifiziert: Live-Test gegen Dev-DB - echte Manipulation einer Zeile wird als
manipuliert erkannt und nicht mit Luecken verwechselt, Ketten-Luecken bleiben
bei 7, Originalzustand exakt wiederhergestellt. tsc + vite build gruen.

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

backend/prisma/migrations/20260818130000_audit_retention_auth_low/migration.sql

@@ -0,0 +1,19 @@
+-- Aufbewahrungsregel fuer routinemaessige Auth-Eintraege (Token-Refresh).
+--
+-- Seit der Entrauschung landen erfolgreiche Token-Refreshes als
+-- `Authentication / LOW`. Diese Kombination traf auf KEINE spezifische Regel
+-- (es gab nur `Authentication / CRITICAL`) und fiel damit in die Auffangregel
+-- `*` mit 3650 Tagen. Ergebnis: Das Rauschen waere 10 Jahre aufbewahrt worden,
+-- echte Logins dagegen nur 2 Jahre - genau verkehrt herum.
+--
+-- 90 Tage reichen, um einen Refresh-Vorgang im Nachhinein nachzuvollziehen.
+-- Idempotent: der Unique-Index (resourceType, sensitivity) verhindert Dubletten.
+INSERT INTO `AuditRetentionPolicy`
+  (`resourceType`, `sensitivity`, `retentionDays`, `description`, `legalBasis`, `isActive`, `createdAt`, `updatedAt`)
+VALUES
+  ('Authentication', 'LOW', 90, 'Routine-Auth (stiller Token-Refresh)', 'Betriebsnotwendigkeit / Datenminimierung (DSGVO Art. 5)', 1, NOW(3), NOW(3))
+ON DUPLICATE KEY UPDATE
+  `retentionDays` = VALUES(`retentionDays`),
+  `description`   = VALUES(`description`),
+  `legalBasis`    = VALUES(`legalBasis`),
+  `updatedAt`     = NOW(3);