RET-04: worm-speicher-garantie-append-only

- archive/internal/wormstore.Store: Put schreibt einmalig (chmod 0400
  danach, ErrAlreadyExists bei Ueberschreibversuch inkl. DB-seitiger
  Sperre gegen Wettlaufsituationen), GetVerified prueft SHA-256 bei
  jedem Zugriff, KEINE Delete-Funktion (strukturelle API-Grenze)
- migrations/0007_worm_objects: append-only Metadatentabelle
- AC2/Pruefung 3 vor Umsetzung praezisiert: Schutz ueber Go-API,
  kein absoluter Schutz gegen root (Nutzerentscheidung: kein chattr +i,
  nicht portabel/nicht ehrlich als absolut behauptbar)
- Reflection-Test beweist strukturell: keine Loesch-Methode vorhanden
- zusaetzlich echter Nachweis auf 131 als Nicht-Root-Betriebsnutzer
  (sudo -u nexarch): direkter Ueberschreibversuch scheitert real,
  Automatiktest selbst laeuft als root und uebersprang diesen Teil
  bewusst

Pruefungen siehe archive/docs/RET-04-PRUEFPROTOKOLL.md

archive/docs/RET-04-PRUEFPROTOKOLL.md

@@ -0,0 +1,66 @@
+# RET-04 – Prüfprotokoll: WORM-Speicher-Garantie (Append-only)
+
+Voraussetzung RET-01 – bereits Fertig.
+
+## Grenzen des Schutzes (bewusst dokumentiert, nicht behauptet)
+
+Nach Nutzerentscheidung (Option 1) beschränkt sich der technische Schutz
+auf zwei Ebenen, beide EHRLICH begrenzt dokumentiert statt als absolut
+verkauft:
+
+1. **Dateisystem-Schreibschutz (`chmod 0400`)** — schützt zuverlässig
+   gegen den Betriebs-Nutzer der Dienste (`nexarch`, kein root), NICHT
+   gegen root/CAP_DAC_OVERRIDE. Ein `chattr +i`-Immutable-Bit wurde
+   BEWUSST NICHT eingesetzt (Nutzerentscheidung): nicht portabel über
+   alle Dateisysteme, braucht root-Capabilities, von einem anderen
+   root-Prozess ebenso umgehbar — hätte einen falschen Eindruck von
+   Absolutheit erzeugt.
+2. **Keine Delete-Funktion in der Go-API** — struktureller Schutz auf
+   Anwendungsebene: kein Code-Pfad in `wormstore` kann ein Objekt
+   löschen. Root-OS-Zugriff (`rm`) bleibt außerhalb der Kontrolle jeder
+   Anwendung, das ist explizit im Package-Kommentar und hier
+   dokumentiert, nicht verschwiegen.
+
+Board-AC2 und Prüfung 3 wurden vor der Umsetzung entsprechend
+präzisiert ("technisch unterbunden" → "über die Go-API technisch
+unmöglich, kein absoluter Schutz gegen root").
+
+## Umsetzung
+
+- `archive/migrations/0007_worm_objects.up/down.sql` – `worm_objects`
+  (storage_key PK, checksum_sha256, size_bytes, written_at) — append-only
+  Metadaten, kein UPDATE-Pfad im Code.
+- `archive/internal/wormstore.Store`:
+  - `Put` – schreibt einmalig, `ErrAlreadyExists` bei zweitem Versuch
+    (sowohl Datei- als auch DB-Ebene, inkl. Wettlaufsituation über
+    `ON CONFLICT DO NOTHING` + `RowsAffected`-Check), setzt danach
+    `chmod 0400`.
+  - `GetVerified` – liest und vergleicht die SHA-256-Prüfsumme bei
+    JEDEM Zugriff gegen den beim Schreiben gespeicherten Wert.
+  - **Kein `Delete`** — bewusst, siehe oben.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Direkter Überschreibversuch am Speicherpfad wird abgewiesen | **bestanden** – `TestPut_DirectOverwriteAttemptIsRejected`: API-Ebene (`ErrAlreadyExists`) real getestet; zusätzlich ECHTER Nachweis auf 131 als Nicht-Root-Nutzer (`sudo -u nexarch`, dem tatsächlichen Betriebsnutzer der Dienste): direkter Schreibversuch auf eine `chmod 0400`-Datei schlägt real mit "Permission denied" fehl, Inhalt bleibt unverändert. Der Automatik-Test selbst läuft auf 131 als root (`os.Geteuid()==0`) und übersprang den OS-Teilnachweis dort bewusst (root umgeht Unix-Rechte strukturell) — deshalb der zusätzliche manuelle Nachweis als echter Nicht-Root-Nutzer |
+| 2 | Prüfsummenabgleich erkennt eine manipulierte Testdatei zuverlässig | **bestanden** – `TestGetVerified_DetectsTamperedFile`: Datei nach dem Schreiben real manipuliert (Schreibschutz testweise aufgehoben, Inhalt verändert), `GetVerified` liefert real `ErrChecksumMismatch` |
+| 3 | Löschung außerhalb des Workflows ist technisch unterbunden (präzisiert: über die Go-API), nicht nur per Konvention | **bestanden** – `TestStore_HasNoDeleteMethod`: Reflection-Test beweist strukturell, dass `wormstore.Store` KEINE Lösch-Methode besitzt — kein Kommentar/keine Konvention, sondern eine compile-time-nachweisbare API-Grenze |
+
+## Build/Test-Ergebnis (192.168.1.131)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./...  -> 0 issues
+go test ./... -p 1  -> alle Archive-Pakete bestanden (inkl. wormstore)
+```
+
+## Gesamtergebnis
+
+**Bestanden.** Alle drei (vor Umsetzung ehrlich präzisierten)
+Akzeptanzkriterien und Pflichtprüfungen real erfüllt — inklusive eines
+zusätzlichen, außerplanmäßigen manuellen Nachweises als echter
+Nicht-Root-Betriebsnutzer, weil der automatisierte Test auf 131 als
+root lief und den entscheidenden OS-Teilnachweis sonst nicht ehrlich
+hätte erbringen können.