Retention-Governance + Heartbeat-Wachhund (Pentest R183, R182-Rest)

R183-01: PUT /retention-policies/{id} nahm retentionDays 0 ohne Bestaetigung an
und protokollierte es als MEDIUM - waehrend cleanup, seal und rehash alle ein
Confirm-Gate haben und die Folge CRITICAL ist. Die geladene Waffe war ungegatet,
der Abzug gegatet. Fix: Absenken verlangt confirm SHORTEN, wird als CRITICAL mit
Vorher/Nachher protokolliert, Untergrenze 30 Tage fuer Authentication/AuditLog.

R183-02: Nach dem Cleanup meldete verify "Keine Manipulation" bei valid:false
und 3010 endgueltig geloeschten Anmeldeprotokollen - der Befund stand nur im
Feld, die Prosa beruhigte. Fix: ehrliche Formulierung bei Luecken, und das
Gegenbuch ruft /verify mit und wertet valid:false hart, egal wie der Text
klingt.

R183-03: verify warnte dauerhaft "Altbestand nicht versiegelt", waehrend
seal-backlog zu Recht ablehnte. Eine unaufloesbare Warnung lernt man zu
ignorieren. Fix: eigener Zustand nicht_noetig, echte Warnung nennt den Befehl.

Heartbeat-Wachhund: Bleibt ein Dienstkonto laenger still als
SERVICE_ACCOUNT_MAX_SILENCE_MINUTES (Standard 180), gibt es SUSPICIOUS/CRITICAL.
Ohne je gesehene Anmeldung wird geschwiegen statt geraten, pro Ausfall genau
eine Meldung. Verifiziert in allen drei Faellen.

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

docs/todo.md

@@ -97,6 +97,40 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🚨 Retention-Governance + Heartbeat-Wachhund (Pentest R183, R182-Rest)** (2026-08-24)
+  - **R183-01 (HIGH)** – Die geladene Waffe war ungegatet, der Abzug gegatet:
+    `PUT /retention-policies/{id}` nahm `retentionDays: 0` **ohne
+    Bestaetigung** an und protokollierte es als MEDIUM – waehrend cleanup,
+    seal und rehash alle ein Confirm-Gate haben und die FOLGE CRITICAL ist.
+    Die ausloesende Tat war leiser als ihre Wirkung.
+    Fix: Absenken verlangt `{"confirm":"SHORTEN"}`, wird als **CRITICAL** mit
+    Vorher/Nachher protokolliert („Aufbewahrung VERKUERZT … 730 → 0 Tage“), und
+    fuer `Authentication`/`AuditLog` gilt eine **Untergrenze von 30 Tagen**.
+    `logChange` nimmt dafuer jetzt Sensitivitaet und Vorzustand entgegen.
+  - **R183-02 (HIGH)** – Nach dem Cleanup meldete verify
+    „**Keine Manipulation.** 656 strukturelle Luecken (alle durch protokollierte
+    Loeschungen erklaert)“ – bei `valid: false` und 3010 endgueltig geloeschten
+    Anmeldeprotokollen. Der Befund stand nur im Feld, die Prosa beruhigte.
+    Dieselbe Alarm-Muedigkeit wie R162/R182, diesmal im Verifizierer selbst.
+    Fix: Bei Luecken heisst es jetzt „Die Kette ist nicht mehr lueckenlos …
+    geloeschte Eintraege lassen sich naturgemaess nicht mehr pruefen“.
+    Zusaetzlich wertet das **Gegenbuch `valid:false` hart** – es ruft
+    `/verify` mit und schlaegt Alarm, egal wie der Text klingt.
+  - **R183-03 (MEDIUM)** – verify warnte dauerhaft „Altbestand nicht
+    versiegelt“, waehrend seal-backlog zu Recht ablehnte („kein Altbestand“).
+    Eine Warnung, die niemand aufloesen kann, lernt man zu ignorieren.
+    Fix: eigener Zustand `nicht_noetig` mit Klartext; die echte Warnung nennt
+    jetzt den Befehl zum Beheben.
+  - **Heartbeat-Wachhund gebaut** (seine wichtigere Haelfte): Bleibt ein
+    Dienstkonto laenger still als `SERVICE_ACCOUNT_MAX_SILENCE_MINUTES`
+    (Standard 180), gibt es `SUSPICIOUS/CRITICAL`. Ohne je gesehene Anmeldung
+    wird geschwiegen statt geraten; pro Ausfall wird genau einmal gemeldet.
+    Verifiziert: keine Grundlinie → still; 500 Minuten Stille → Meldung;
+    Wiederholung → keine Dublette.
+  - Seine Non-Findings bestaetigt uebernommen: Confirm-Gates gegen neun
+    Umgehungsvarianten dicht, rehash-Protokoll ehrlich, Tombstone-Mechanik und
+    Anker-Backstop intakt.
+
 - [x] **🔧 Gegenbuch-Container: Rechte am Bind-Mount selbst geraderuecken** (2026-08-22)
   - Fehlerbild aus dem echten Betrieb: `mkdir: cannot create directory
     '/gegenbuch/schluessel': Permission denied`, Container in der