feat(archive): RET-01 generisches Retention-Objektmodell

internal/retention: object_type/object_reference als reine Textfelder
(Adapter-Muster, keine Fremdschluessel auf DMS-/Mail-Tabellen).
Aufbewahrungsklassen-Zuordnung historisiert (jede Zuordnung eigene,
unveraenderliche Zeile). Migration real vorwaerts+rueckwaerts gegen
die tatsaechlichen .sql-Dateien getestet, Mandantentrennung gegen
echtes zweites Tenant-DB bewiesen. Grundlage fuer RET-05 (Adapter-
Interface) und RET-02.

archive/docs/RET-01-PRUEFPROTOKOLL.md

@@ -0,0 +1,64 @@
+# RET-01 – Prüfprotokoll: Generisches Retention-Objektmodell
+
+Keine Vorbedingungen (Welle 1 des RET-Epics).
+
+## Grundsatzentscheidung: Adapter-Muster, keine Fremdschlüssel auf Modul-Tabellen
+
+`retention_objects.object_type`/`object_reference` sind reine
+Textfelder — Archive importiert weder DMS- noch Mail-Code (eigene
+Go-Module, physisch getrennte Verantwortung, dieselbe Disziplin wie
+BAK-05s `reconcile`-Paket gegenüber `file_revisions`). Ein neues Modul
+kann retention-pflichtige Objekte einbinden, ohne dieses Paket zu
+ändern — nur `RegisterObject(objectType, objectReference)` aufrufen.
+
+Aufbewahrungsklassen-Zuordnung ist historisiert: `AssignClass` fügt
+IMMER eine neue Zeile hinzu, ändert nie eine bestehende — die "aktuelle"
+Klasse ist die mit dem jüngsten `assigned_at`. Damit bleibt
+nachvollziehbar, wann und wie oft sich die Klasse eines Objekts
+geändert hat, ohne eigene Audit-Tabelle.
+
+## Umsetzung
+
+- `migrations/0002_retention.up.sql`/`.down.sql` — `retention_objects`,
+  `retention_class_assignments`.
+- `internal/retention.RegisterObject` — idempotent (`ON CONFLICT`).
+- `internal/retention.AssignClass`/`CurrentClass`/`ClassHistory`.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Migration vorwärts und rückwärts getestet | **bestanden** — `TestMigration_ForwardAndBackward`: real gegen die tatsächlichen Migrationsdateien (nicht nachgebaut), vorwärts→Tabellen vorhanden, rückwärts→Tabellen weg, erneut vorwärts→sauber (kein Rest blockiert erneuten Lauf) |
+| 2 | Testobjekt aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet | **bestanden** — `TestRegisterObject_MapsDMSAndMailAdapterObjectsIdentically`: `dms_document`/`mail_message` beide ohne modulspezifische Spalten abgebildet, zusätzlich Idempotenz bewiesen (erneute Registrierung liefert dieselbe ID) |
+| 3 | Tenant-Isolation der Kern-Tabellen durch Negativtest belegt | **bestanden** — `TestTenantIsolation_Negativtest`: reales zweites Tenant-DB (`ret01_tenant_test_b`), Objekt aus Tenant A über Verbindung zu Tenant B abgefragt, `count=0` — technisch nicht sichtbar, keine gemeinsame Tabelle mit `tenant_id`-Filter (Modell C, TEN-01) |
+
+Zusätzlich: `TestAssignClass_IsHistoricized` — zwei Klassen-Zuordnungen,
+`CurrentClass` liefert die jüngste, `ClassHistory` beide chronologisch.
+
+## Echte Verdrahtung auf 192.168.1.131
+
+- Migration real gegen `dms_tenant_test` angewendet (`psql -f
+  migrations/0002_retention.up.sql`) — `retention_objects`,
+  `retention_class_assignments` bestätigt vorhanden (`\dt retention*`)
+- Kein systemd-Dienst/Timer nötig — RET-01 ist reines Datenmodell +
+  Bibliothek, kein eigenständiger Prozess (Verbraucher sind spätere
+  RET-Tickets, allen voran RET-05 als Adapter-Interface)
+- Zweites Tenant-DB (`ret01_tenant_test_b`) nur für den Isolationstest
+  angelegt, danach entfernt
+
+## Build/Test-Ergebnis (192.168.1.131, `make check`)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./...  -> 0 issues
+go test ./... -p 1 -count=1  -> 8/8 Pakete mit Tests ok (backup, objectbackup, reconcile, restore, restoretest, retention, scrub, tenantbackup), 0 Fehlschläge
+```
+
+## Gesamtergebnis
+
+**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
+Pflichtprüfungen real erfüllt — Migration gegen die tatsächlichen
+`.sql`-Dateien (nicht nachgebaut) getestet, Mandantentrennung gegen ein
+echtes zweites Tenant-DB bewiesen. Grundlage für RET-05 (Adapter-
+Interface, als Nächstes) und RET-02 gelegt.