Audit-Integritaet: Dauer-Fehlalarm ueber 67 % des Logs behoben

verifyIntegrity meldete 3107 von 4630 Zeilen als "manipuliert" - davon 3100
Fehlalarme, exakt die Zeilen mit resourceId = NULL aus 08.02.-01.05.2026.

Ursache: Der R121-Fix nahm an, resourceId sei beim Schreiben immer undefined
gewesen (Key faellt bei JSON.stringify weg) und daher wuerden alle
Bestands-Hashes ohne Rehash matchen. Das gilt erst ab ~01.05.2026 - aeltere
Zeilen wurden mit explizitem null serialisiert, der Key war drin.

Sicherheitsrelevant, weil ein staendig grundlos ausloesender Alarm ignoriert
wird - echte Manipulation ginge im Laerm unter.

Fix: generateHashLegacy() reproduziert das alte Schreibverhalten,
verifyIntegrity akzeptiert Altbestand ueber diesen Fallback (nur geprueft,
wenn die aktuelle Variante nicht passt). Bewusst KEIN Rehash - der wuerde die
Manipulations-Beweiskraft der Vergangenheit zerstoeren. Gespeicherte Hashes
bleiben unangetastet.

Verifiziert: ungueltig 3107 -> 7 (echte Ketten-Brueche). Adversarial
gegengetestet: Manipulation an userEmail/action/endpoint/createdAt/resourceId
wird bei alten wie neuen Zeilen zu 100 % erkannt (10/10). tsc gruen.

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

docs/todo.md

@@ -97,6 +97,29 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🛡️ Audit-Integritaet: Dauer-Fehlalarm ueber 67 % des Logs behoben** (2026-08-18)
+  - Beim Nachpruefen aufgefallen: `verifyIntegrity` meldete **3107 von 4630**
+    Zeilen als „manipuliert“. Davon waren **3100 Fehlalarme** – eingegrenzt auf
+    exakt die Zeilen mit `resourceId = NULL` aus dem Zeitraum 08.02.–01.05.2026.
+  - Ursache: Der R121-Fix nahm an, `resourceId` sei beim Schreiben immer
+    `undefined` gewesen (Key faellt bei `JSON.stringify` weg) und daher wuerden
+    **alle** Bestands-Hashes ohne Rehash matchen. Das gilt erst ab ~01.05.2026 –
+    aeltere Zeilen wurden mit explizitem `null` serialisiert, der Key war DRIN.
+  - Warum das sicherheitsrelevant ist: Ein Alarm, der staendig grundlos
+    ausloest, wird ignoriert – **echte** Manipulation ginge im Lärm unter
+    (gleiches Muster wie beim Refresh-Rauschen, [R165]).
+  - Fix: `generateHashLegacy()` reproduziert das alte Schreibverhalten;
+    `verifyIntegrity` akzeptiert Altbestand ueber diesen Fallback (nur geprueft,
+    wenn die aktuelle Variante nicht passt). **Kein Rehash** – der waere der
+    naheliegende Schnellfix, wuerde die Manipulations-Beweiskraft der
+    Vergangenheit aber unwiederbringlich zerstoeren. Gespeicherte Hashes
+    bleiben unangetastet.
+  - Verifiziert: ungueltige Zeilen **3107 → 7** (die 7 sind echte Ketten-Brueche,
+    siehe naechster Punkt). Adversarial gegengetestet: Manipulation an
+    `userEmail`/`action`/`endpoint`/`createdAt`/`resourceId` wird bei ALTEN wie
+    NEUEN Zeilen weiterhin zu 100 % erkannt (10/10), unveraenderte Zeilen
+    akzeptiert. `tsc` gruen.
+
 - [x] **🐛 Audit-Log: Pfad-Matching kaputt – Auth-Actions generisch (Pentest R165-01)** (2026-08-18)
   - Pentester meldete: Entrauschung (`de0d6bd`) live **nicht wirksam** – jeder
     `/refresh` weiter `CREATE / CRITICAL / „Anmeldung erstellt“`. Zusatzbefund: