feat(archive): BAK-03 Restore-Verfahren fuer Datenbank und Objekt-Storage

internal/restore: Atomarer Restore ueber Temp-Verzeichnis + Rename,
nicht-leeres Ziel ohne -force bricht VOR jeder Beruehrung ab, JSONL-
Protokoll jedes Laufs. Drei reale Defekte beim Bau gefunden und behoben:
pg_combinebackup braucht Plain- statt Tar-Format (Extraktionsschritt
ergaenzt), pg_wal.tar.gz wurde nie verifiziert/wiederhergestellt (BAK-01s
Verify jetzt erweitert), Go-exec haengt bei pg_ctl start wegen vererbter
Pipes (Testfix: echte Logdatei statt CombinedOutput). Beide Restore-Pfade
real auf 131 ueber restore-cli nachgewiesen, inkl. echtem Postgres-Start
aus wiederhergestelltem Verzeichnis.

archive/docs/BAK-01-PRUEFPROTOKOLL.md

@@ -85,3 +85,13 @@ nachweislich am neuen Ort.
 real erfüllt — inklusive tatsächlicher systemd-Timer-Installation und
 manuell ausgelöstem End-to-End-Lauf aller drei Dienste auf dem Testhost,
 nicht nur isolierter Testcode.
+
+## Nachtrag (BAK-03): Verify prüft jetzt auch pg_wal.tar.gz
+
+Beim Bau von BAK-03s echtem Restore-Test fiel auf, dass `pg_basebackup`
+(Standard-WAL-Methode `stream`) bei `-Ft -z` NEBEN `base.tar.gz` eine
+zweite Archivdatei `pg_wal.tar.gz` erzeugt, die `Verify` bislang nie
+geprüft hat — eine Sicherung mit beschädigtem WAL-Archiv wäre unbemerkt
+nicht crash-konsistent wiederherstellbar gewesen. `Verify` prüft seither
+beide Archive vollständig (siehe `BAK-03-PRUEFPROTOKOLL.md`). Das
+Sicherungsverfahren selbst (Format, Ort, Rotation) bleibt unverändert.