Siegel-Entfernung wird erkannt (Pentest R174-01, HIGH)

Der Siegelzustand hing ausschliesslich am Marker im Audit-Log - und den kann
ein DB-Schreiber ohne Schluessel loeschen. Danach meldete die Pruefung
kein_siegel, also Entwarnung, ununterscheidbar von "nie versiegelt". Die
Blattwerte blieben verwaist liegen und wurden nie konsultiert, die zuvor
erkannte V1-Faelschung war wieder unsichtbar.

Besonders bitter im Tail-Fall: Steht der Marker am Ketten-Ende - genau der
Zustand direkt nach dem einmaligen seal-backlog beim Deploy - reisst beim
Loeschen nicht einmal eine Luecke. Ergebnis war valid:true und "Alle Eintraege
unveraendert und lueckenlos verkettet", also null Spur. Meine Antwort auf die
Frage des Pentesters war damit falsch: die Luecke reisst nur, solange der
Marker nicht am Ende steht.

Fix: Gegen-Check "Blaetter vorhanden, aber kein gueltiger Marker" -> neuer
Status entfernt statt kein_siegel, mit ausdruecklicher Meldung. Ein gebrochenes
oder entferntes Siegel kippt jetzt valid auf false, auch ohne beanstandete
Einzelzeile. Der beruhigende Einstiegssatz entfaellt bei Siegelproblemen.

Verifiziert ueber den echten HTTP-Pfad, exakt Szenario 4: Marker nachweislich
das Ketten-Ende, Marker + Middleware-Decoy geloescht, 0 Ketten-Luecken ->
valid:false, Status entfernt, Klartext-Warnung. Auch der Nicht-Tail-Fall
geprueft. Wegwerf-Datenbanken danach geloescht, Dev unberuehrt.

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

docs/todo.md

@@ -97,6 +97,36 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🚨 Siegel-Entfernung wird erkannt (Pentest R174-01, HIGH)** (2026-08-18)
+  - Fund: Der Siegelzustand hing **ausschliesslich** am Marker im Audit-Log –
+    und den kann ein DB-Schreiber **ohne Schluessel** loeschen. Danach meldete
+    die Pruefung `kein_siegel`, also **Entwarnung**, ununterscheidbar von „nie
+    versiegelt“. Die 11 Blattwerte blieben verwaist liegen und wurden nie
+    konsultiert; die zuvor erkannte V1-Faelschung war wieder unsichtbar.
+  - Besonders bitter im **Tail-Fall**: Steht der Marker am Ketten-Ende – genau
+    der Zustand direkt nach dem einmaligen `seal-backlog` beim Deploy – reisst
+    beim Loeschen nicht einmal eine Luecke. Ergebnis war `valid: true`,
+    „Alle Einträge unverändert und lückenlos verkettet“, **null Spur**. Meine
+    Antwort auf seine Frage (b) war damit falsch: die Luecke reisst nur,
+    solange der Marker NICHT am Ende steht.
+  - Fix (sein Vorschlag): Gegen-Check „Blaetter vorhanden, aber kein gueltiger
+    Marker“ → neuer Status **`entfernt`** statt `kein_siegel`, mit
+    ausdruecklicher Meldung („Das ist KEIN Normalzustand“). Zusaetzlich kippt
+    ein gebrochenes ODER entferntes Siegel jetzt `valid` auf `false`, auch wenn
+    keine einzelne Zeile beanstandet ist – sonst bliebe der stille Anker-Verlust
+    ohne Wirkung. Und der beruhigende Einstiegssatz entfaellt bei
+    Siegelproblemen, damit er die Warnung nicht entwertet.
+  - Verifiziert ueber den echten HTTP-Pfad, exakt sein Szenario 4: Marker war
+    nachweislich das Ketten-Ende, Marker + Middleware-Decoy geloescht,
+    **0 Ketten-Luecken** – Ergebnis jetzt `valid: false`, Status `entfernt`,
+    Klartext-Warnung. Zusaetzlich der Nicht-Tail-Fall geprueft. Zwei
+    Wegwerf-Datenbanken, beide danach geloescht; Dev unberuehrt.
+    `tsc` + `vite build` gruen.
+  - Seine Gegenchecks bestaetigt: Frage (a) Middleware kann keine Marker-/
+    Manifest-Signatur mit auswertbarem Inhalt nachbilden; Frage (c)
+    Re-Insert mit derselben id umgeht nichts, weil das Blatt alle Spalten
+    deckt.
+
 - [x] **🔧 Bestandssiegel betriebstauglich gemacht (Pentest R173-01 HIGH, R173-02/-03 MEDIUM)** (2026-08-18)
   - **R173-01 (HIGH) – Siegel war ueber HTTP tot.** Die generische
     `auditMiddleware` protokolliert den `POST /seal-backlog`-Request SELBST als