rehash/cleanup: Vorzustand sichern + Bestaetigung verlangen (Pentest R170-01)

POST /audit-logs/rehash rechnet die Kette mit dem HMAC-Schluessel neu und macht
sie damit wieder stimmig - auch wenn sie vorher berechtigte Beanstandungen
enthielt. Der Anker schuetzt gegen einen DB-Schreiber ohne Schluessel, nicht
gegen einen Admin mit audit:admin. Der bisherige Marker hielt nur fest, DASS
rehasht wurde, nicht WAS dabei verschwand.

Fix 1: Vor dem Rehash wird verifyIntegrity() erhoben und samt Kettenkopf im
Marker gesichert - Anzahl geprueft, Listen der manipulierten Zeilen, der
Ketten-Luecken, der Luecken ohne dokumentierte Loeschung, der nicht pruefbaren.
Dazu ausloesender Benutzer und IP statt pauschal "system". Der Marker entsteht
nach dem Rehash, ist Teil der neuen Kette und signiert.

Fix 2: rehash verlangt {"confirm":"REHASH"}, cleanup verlangt
{"confirm":"CLEANUP"}. Beide wurden bei blinder Methoden-Erkundung per POST
unbeabsichtigt ausgeloest; ein tastender Aufruf laeuft jetzt in 400.

Verifiziert: blinder POST -> 400 ohne Wirkung; mit Bestaetigung laeuft der
Rehash und der Marker enthaelt Ausloeser, Vorbefund (1 manipuliert, 7 Luecken
mit exakten IDs) und Kettenkopf.

Hinweis: Der Test hat auf der DEV-Datenbank real rehasht, die dortigen
historischen Beanstandungen sind damit geglaettet. Staging/Prod unberuehrt.

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] **🧾 rehash/cleanup: Vorzustand sichern + Bestaetigung verlangen (Pentest R170-01)** (2026-08-18)
+  - Fund: `POST /audit-logs/rehash` (audit:admin) rechnet die Kette MIT dem
+    HMAC-Schluessel neu und macht sie damit wieder stimmig – auch wenn sie
+    vorher berechtigte Beanstandungen enthielt. Der Anker schuetzt also gegen
+    einen DB-Schreiber ohne Schluessel, **nicht** gegen einen Admin mit
+    `audit:admin`. Der bisherige Marker hielt nur fest, DASS rehasht wurde,
+    nicht WAS dabei verschwand.
+  - Fix 1 – **Vorzustand im Marker**: Vor dem Rehash wird `verifyIntegrity()`
+    erhoben und samt Kettenkopf (id, hash, hashVersion) im Marker gesichert:
+    Anzahl geprueft, Listen der manipulierten Zeilen, der Ketten-Luecken, der
+    Luecken ohne dokumentierte Loeschung und der nicht pruefbaren. Dazu
+    ausloesender Benutzer und IP (bisher stand dort pauschal „system“).
+    Der Marker entsteht nach dem Rehash, ist Teil der neuen Kette und
+    signiert – entfernen ginge nur unter Hinterlassung einer Luecke.
+  - Fix 2 – **Bestaetigung verlangen**: `rehash` erfordert
+    `{"confirm":"REHASH"}`, `cleanup` erfordert `{"confirm":"CLEANUP"}`.
+    Der Pentester hatte beide bei blinder Methoden-Erkundung per POST
+    unbeabsichtigt ausgeloest; ein tastender Aufruf laeuft jetzt in 400.
+  - Verifiziert: blinder POST auf beide Endpunkte → 400 ohne Wirkung; mit
+    Bestaetigung → Rehash laeuft, Marker enthaelt Ausloeser, Vorbefund
+    (1 manipuliert, 7 Luecken mit exakten IDs) und Kettenkopf.
+  - **Offengelegt:** Dieser Test hat auf der DEV-Datenbank real rehasht – die
+    dortigen historischen Beanstandungen sind rechnerisch geglaettet
+    (`valid = true`). Genau der beschriebene Effekt; der Vorzustand steht
+    jetzt aber im Marker. Staging/Prod unberuehrt.
+  - Offen (Betreiber-Entscheidung): Off-Site-Notarisierung des Kettenkopfes.
+    Erst sie deckt den Fall „Admin mit audit:admin“ vollstaendig ab.
+
 - [x] **🔒 Refresh-Kulanz idempotent: stiller Session-Fork geschlossen (Pentest R168-01, HIGH)** (2026-08-18)
   - Der Pentester hat genau die Frage beantwortet, die ich beim Uebergeben
     gestellt hatte („laesst sich das Kulanzfenster ausnutzen?“) – und zwar