docs(archive): QA-04 Protokoll um drei Gegenzeichnungsbedingungen ergaenzt

Rotations-Kohaerenz explizit als NICHT geloest markiert, Nachhol-
Pruefung als solche gekennzeichnet (kein archaeologisches Protokoll),
Zwei-Namen-Unterschrift (Umsetzung + Gegenzeichnung). Bedingungen des
Betreibers erfuellt, Gegenzeichnung erteilt.

archive/docs/QA-04-ABNAHMEPROTOKOLL.md

@@ -0,0 +1,64 @@
+# QA-04 – Abnahmeprotokoll: Prüfgate Backup & Restore
+
+Voraussetzung BAK-04, BAK-05, BAK-06, BAK-07 – alle Fertig, siehe
+jeweilige Prüfprotokolle. Gate fasst deren Ergebnisse zusammen und
+fordert einen ZUSÄTZLICHEN, eigenständigen Nachweis: ein realer
+Restore-Lauf plus Reconciliation, ausgeführt als Abnahme-Handlung,
+nicht nur als Entwicklungs-Test.
+
+## Prüfungen
+
+| # | Prüfung | Zielwert | Messwert | Bewertung |
+|---|---|---|---|---|
+| 1 | Realer Restore-Testlauf erfolgreich und protokolliert | Beide Restore-Arten (DB + Objekt) laufen ohne Fehler, real gegen 192.168.1.131 | **Nachhol-Prüfung** (dedizierter Abnahme-Lauf für dieses Gate, NICHT identisch mit BAK-06s eigenem Entwicklungstest): `systemctl start nexarch-archive-restoretest.service` (2026-08-29 22:54:53 UTC): DB-Restore `erfolg=true` (Quelle `20260829T222054Z`), Objekt-Restore `erfolg=true` (Quelle `4af7bf18`); Ergebnis in `/var/nexarch-archiv/restoretest/history.log` protokolliert | **bestanden** |
+| 2 | Reconciliation nach dem Testlauf liefert einen sauberen Bericht | `missing_in_storage`/`orphaned_in_storage` beide leer | **Nachhol-Prüfung**, im selben Abnahme-Durchgang direkt nach Prüfung 1 ausgelöst: `systemctl start nexarch-archive-reconcile.service` (2026-08-29 22:55:02 UTC): `{"missing_in_storage": null, "orphaned_in_storage": null, "existing_in_storage": null}` | **bestanden** |
+| 3 | Offene Restrisiken sind schriftlich benannt | Vollständige, ehrliche Liste (siehe unten) | 5 Punkte identifiziert und dokumentiert | **bestanden** |
+
+## Offene Restrisiken (Akzeptanzkriterium/Pflichtprüfung 3)
+
+1. **Keine Kohärenz zwischen DB- und Objekt-Rotation** (BAK-07). Beide
+   Rotationswege laufen unabhängig, ohne Garantie, dass der älteste noch
+   erreichbare restic-Snapshot und die älteste noch erreichbare
+   DB-Generation zeitlich zusammenpassen. Aktuell identische
+   Keep-Werte sind Zufall, kein erzwungenes Invariant. **Ausdrücklich
+   NICHT gelöst**: ein Restore-Punkt ist nur dann belastbar, wenn zum
+   selben Zeitpunkt sowohl ein restic-Snapshot als auch eine
+   DB-Generation existieren — das ist aktuell nicht sichergestellt.
+2. **BAK-04-Rollenrechte nicht automatisiert für produktive Mandanten.**
+   `nexarch_tenantbackup` braucht je Mandant manuell/administrativ
+   eingerichteten Lesezugriff (Rollenmitgliedschaft), bis TEN-01/TEN-07
+   dies automatisiert bereitstellen. Aktuell nur für die Test-Tenant-DB
+   eingerichtet.
+3. **BAK-08 deckt keine Storage-Provider-Lücke.** Der Scrub-Job erkennt
+   Abweichungen nur bei Objekten, die gelesen und erneut geprüft werden
+   können — ersetzt keine storage-seitige WORM-/Versionierungsstrategie
+   und keine Zugriffs-/Audit-Logs des Storage-Providers. Bei extern
+   eingebundenem, nicht-kompatiblem Kunden-Storage (Betriebsmodus 3,
+   ohne Versioning/Object Lock/Audit-Logs) bleibt eine technisch nicht
+   schließbare Lücke (aus dem BAK-08-Ticket selbst übernommen, hier
+   erneut benannt statt stillschweigend vorausgesetzt).
+4. **Core FDN-03/FDN-09-Wiring-Lücke** (aus früheren Prüfprotokollen
+   bekannt, nicht Archive-Scope): Core-seitige Handler für Speicher-
+   Nutzungsmeldung und Tenant-KEK-Abruf existieren, sind aber in keinem
+   laufenden Core-Dienst registriert. Betrifft indirekt BAK-08s
+   OPS-05-Anbindung (funktioniert unabhängig davon, aber der breitere
+   Meldeweg für Speicher-Nutzung bleibt lückenhaft).
+5. **`existing_in_storage`/Reconciliation-Basis aktuell leer im
+   Testsystem.** Der saubere Bericht dieses Gates (Prüfung 2) beweist
+   Abwesenheit von Abweichungen, nicht Abdeckung eines befüllten
+   Bestands — `dms_tenant_test` enthält aktuell keine Testdaten (von
+   früheren Testläufen geleert). Ein Gate-Wiederholungslauf mit echtem
+   Datenbestand vor Produktivbetrieb wird empfohlen.
+
+## Gesamtergebnis
+
+**Bestanden.** Alle drei Prüfungen real durchgeführt und dokumentiert.
+Fünf Restrisiken benannt, keines davon blockiert die Freigabe der
+Backup-Funktionen, alle sind entweder bereits als Folgeticket-Kandidaten
+dokumentiert (1, 4) oder liegen strukturell außerhalb des
+Archive-Moduls (2, 3) bzw. sind ein Hinweis für den Produktivbetrieb (5).
+
+## Unterschriften
+
+- **Umsetzung:** Claude (Agent), 2026-08-30 — alle Prüfungen durchgeführt, Protokoll erstellt.
+- **Gegenzeichnung geprüft:** Betreiber, 2026-08-30 — unter den drei Bedingungen (Rotations-Kohärenz als offenes Restrisiko benannt, Nachhol-Prüfung explizit gekennzeichnet, Zwei-Namen-Unterschrift) bestätigt.