CMP-02: dsgvo-datenschutz-berichte

- migrations/0009_data_subject_ref: additive nullable Spalte auf
  retention_objects, schliesst die Luecke fuer 'betroffene Person' in
  RET-01
- retention.RegisterObjectForSubject: NEUE additive Funktion, RegisterObject
  selbst unveraendert (kein Diff, keine Produktionsaufrufer betroffen)
- archive/internal/dpreport: SubjectReport (Auskunftsbericht),
  ProcessingOverview (Verarbeitungsuebersicht, statisch gepflegte
  Zweck/Rechtsgrundlage je Objekttyp), WriteSubjectReportCSV
- Mandantentrennung strukturell durch Modell C (ein Pool pro Tenant),
  real mit zwei physisch getrennten Tenant-DBs bewiesen (tenant_acme/
  tenant_globex), nicht nur behauptet
- 4 Tests, alle Pflichtpruefungen real bestanden
- Migration real auf dms_tenant_test angewendet

Pruefungen siehe archive/docs/CMP-02-PRUEFPROTOKOLL.md

archive/docs/CMP-02-PRUEFPROTOKOLL.md

@@ -0,0 +1,69 @@
+# CMP-02 – Prüfprotokoll: DSGVO-/Datenschutz-Berichte
+
+Voraussetzung RET-01 – bereits Fertig.
+
+## Vorab identifizierte und geklärte Design-Lücke
+
+RET-01 (`retention_objects`) führte bislang keine Zuordnung zu einer
+"betroffenen Person" — nur `object_type`/`object_reference` (opake
+modulübergreifende Referenz). Ein Auskunftsbericht "aller Objekte einer
+Person" war damit strukturell unmöglich. Nach Nutzerentscheidung
+(Option 1) additiv gelöst:
+
+- `archive/migrations/0009_data_subject_ref.up.sql` — nullable Spalte
+  `retention_objects.data_subject_ref` + Index.
+- `archive/internal/retention.RegisterObjectForSubject` — NEUE, additive
+  Funktion. `RegisterObject` (RET-01) bleibt UNVERÄNDERT (kein Diff),
+  kein bestehender Aufrufer betroffen (Codeprüfung: `RegisterObject`
+  hatte ohnehin nur Testaufrufer, keine Produktionsverdrahtung).
+- Leeres `data_subject_ref` bedeutet "nicht personenbezogen", kein
+  Fehlerzustand (z. B. Systemkonfigurationsobjekte).
+
+## Umsetzung
+
+- `archive/internal/dpreport.SubjectReport` – Auskunftsbericht
+  (Akzeptanzkriterium 1), nutzt dieselbe "jüngste Zuordnung"-Logik wie
+  RET-02 (DISTINCT ON), keine zweite Berechnung.
+- `archive/internal/dpreport.ProcessingOverview` – Verarbeitungsübersicht
+  je tatsächlich vorkommendem Objekttyp (Akzeptanzkriterium 2), Zweck/
+  Rechtsgrundlage statisch gepflegt (`ProcessingPurposes`) — Rechts-
+  bewertungen sind keine aus Nutzdaten ableitbaren Werte.
+- `archive/internal/dpreport.WriteSubjectReportCSV` – CSV-Export
+  (Akzeptanzkriterium/Pflichtprüfung 3).
+- **Mandantentrennung (Akzeptanzkriterium 3):** strukturell garantiert
+  durch Modell C — `SubjectReport` läuft immer gegen GENAU EINEN
+  Tenant-Pool, kein Cross-Tenant-Query technisch möglich.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Auskunftsbericht für Testperson mit bekanntem Datenbestand stimmt mit erwarteter Liste überein | **bestanden** – `TestSubjectReport_MatchesKnownDataset`: 3 Objekte für 2 Personen angelegt, Bericht für Person A liefert exakt die 2 erwarteten Objekte (nicht das dritte, das Person B gehört), inkl. korrekter Aufbewahrungsklasse |
+| 2 | Bericht für einen Tenant enthält keine Objekte eines anderen Tenants | **bestanden** – `TestSubjectReport_TenantIsolation`: real gegen ZWEI PHYSISCH GETRENNTE Tenant-Datenbanken (`tenant_acme`, `tenant_globex`) getestet, nicht nur zweimal dieselbe DSN — Objekt in Tenant A angelegt, Bericht für dieselbe `data_subject_ref` gegen Tenant B liefert 0 Treffer |
+| 3 | Export lässt sich als CSV weiterverarbeiten | **bestanden** – `TestWriteSubjectReportCSV_IsParseable`: echte CSV-Ausgabe erzeugt und geparst, Header + genau eine Datenzeile |
+
+**Hinweis zur Testkorrektur:** Der erste Testlauf von Prüfung 2 nutzte
+versehentlich denselben `TEST_TENANT_DSN` für beide "Tenants" (dieselbe
+physische Datenbank) und schlug dadurch zurecht fehl — kein
+Code-Defekt, sondern ein Testfehler. Korrigiert auf zwei echte,
+unabhängige Tenant-Datenbanken (`TEST_TENANT_DSN_B`), danach real
+bestanden.
+
+## 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. dpreport, retention)
+```
+
+Migration `0009_data_subject_ref` real auf `dms_tenant_test` angewendet.
+
+## Gesamtergebnis
+
+**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
+Pflichtprüfungen real erfüllt, inklusive einer vorab identifizierten
+und mit dem Nutzer geklärten strukturellen Lücke (fehlende
+Personen-Zuordnung in RET-01), additiv und ohne Änderung an bestehendem
+Verhalten geschlossen.