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>

docs/todo.md

@@ -97,6 +97,34 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔎 Audit-Pruefung: „manipuliert“ von „Luecke“ getrennt + Retention fuer Routine-Auth** (2026-08-18)
+  - **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 wurde dadurch
+    wertlos (dasselbe Muster wie beim Refresh-Rauschen).
+  - Fix: Rueckgabe um `tamperedEntries` (Inhalt einer Zeile nachtraeglich
+    veraendert – **ernst**) und `chainGaps` (Verkettung unterbrochen durch
+    parallele Schreibvorgaenge oder geloeschte Zeilen – **meist harmlos**)
+    erweitert. `invalidEntries` bleibt als Summe erhalten
+    (Abwaertskompatibilitaet). Controller formuliert die Meldung entsprechend
+    eindeutig; Frontend-API-Typ nachgezogen.
+  - **Problem 2 (Aufbewahrung):** Seit der Entrauschung landen Token-Refreshes
+    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 (730 Tage).
+  - Fix: Regel `Authentication / LOW` → 90 Tage. Als Migration
+    (`20260818130000`, idempotent per `ON DUPLICATE KEY`) **und** im Seed, damit
+    sie sowohl bestehende Installationen als auch Neuinstallationen erreicht.
+  - Hinweis zur Sensitivitaet: Sie steuert die Aufbewahrung, ist also **keine**
+    Alarmstufe. Normale Logins/Logouts sowie Zugriffe auf Bankdaten/Ausweise
+    bleiben bewusst CRITICAL. Ein Herabstufen „fuer eine ruhigere Liste“ wuerde
+    still die Aufbewahrungsfrist verlaengern – daher unterlassen.
+  - Verifiziert: Live-Test gegen Dev-DB – echte Manipulation einer Zeile
+    (`UPDATE … SET userEmail`) wird als **manipuliert** erkannt und nicht mit
+    Luecken verwechselt; Ketten-Luecken bleiben bei 7; Originalzustand exakt
+    wiederhergestellt (0 manipuliert danach). `tsc` + `vite build` gruen.
+
 - [x] **🔗 Audit-Kette: Race beim Fortschreiben behoben (parallele Requests)** (2026-08-18)
   - `createAuditLog` las den Vorgaenger-Hash und schrieb den neuen Eintrag als
     zwei getrennte Schritte. Zwei parallele Requests lasen denselben letzten