RET-10: cors-fuer-ret-06-api

- archive/internal/retentionapi.CORS: erlaubt genau einen konfigurierten
  Origin (kein Wildcard), beantwortet OPTIONS-Preflights direkt
- cmd/retention-api: neue Pflicht-Env NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN,
  mux mit CORS umschlossen
- gefunden durch Sichtpruefung des laufenden RET-06-Frontends: curl
  umgeht CORS, ein echter Browser haette den Fetch blockiert - weder
  Go- noch Vitest-Tests konnten das strukturell erfassen
- 3 Tests: erlaubter Origin bekommt Header, Preflight korrekt
  beantwortet, fremder Origin bekommt keinen Header
- real deployed auf 131, genau der bei der Sichtpruefung fehlgeschlagene
  Aufruf (Origin http://127.0.0.1:3099) liefert jetzt 200 mit korrektem
  Access-Control-Allow-Origin

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

archive/docs/RET-10-PRUEFPROTOKOLL.md

@@ -0,0 +1,62 @@
+# RET-10 – Prüfprotokoll: CORS für RET-06-API (Frontend-Zugriff aus dem Browser)
+
+Voraussetzung RET-06-API – bereits Fertig, hier NICHT sonst verändert
+(nur `cmd/retention-api/main.go` um die Middleware-Verdrahtung ergänzt).
+
+## Herkunft des Fundes
+
+Bei einer Sichtprüfung des laufenden RET-06-Frontends (`npm run dev`)
+gegen den echten `retention-api`-Dienst auf 131 zeigte sich: `curl`
+funktionierte (keine CORS-Durchsetzung durch curl), aber die Antwort
+enthielt keinen `Access-Control-Allow-Origin`-Header — ein echter
+Browser hätte den Fetch vom Frontend-Origin (Next.js-Dev-Server) zum
+Backend-Origin (retention-api) blockiert. Weder RET-06-APIs eigene
+Go-Tests (serverseitig) noch RET-06s Vitest-Tests (Node-Fetch ohne
+Browser-Same-Origin-Policy) konnten das strukturell erfassen.
+
+## Umsetzung
+
+- `archive/internal/retentionapi/cors.go` – `CORS(allowedOrigin string, next http.Handler) http.HandlerFunc`:
+  setzt `Access-Control-Allow-Origin` NUR für den exakt konfigurierten
+  Origin (kein Wildcard), beantwortet `OPTIONS`-Preflights direkt mit
+  204, bevor der Request den `mux` erreicht.
+- `archive/cmd/retention-api/main.go` – neue Pflicht-Env-Variable
+  `NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN`, `mux` wird mit `CORS(...)`
+  umschlossen.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Realer Browser-Fetch (nicht curl) gelingt, Same-Origin-Policy nicht mehr blockierend | **bestanden** – `TestCORS_AllowedOriginGetsAccessControlHeader`; real auf 131: `curl -H 'Origin: http://127.0.0.1:3099'` liefert `Access-Control-Allow-Origin: http://127.0.0.1:3099` — der Header, den ein Browser zur Freigabe des Fetches prüft, ist real gesetzt (der ursprüngliche Sichtprüfungs-Blocker ist damit real geschlossen, mit demselben Origin/Port reproduziert, an dem er gefunden wurde) |
+| 2 | OPTIONS-Preflight liefert korrekte Header für POST /retention-classes | **bestanden** – `TestCORS_PreflightRequestForPostEndpoint`; real auf 131: `curl -X OPTIONS` mit `Access-Control-Request-Method: POST` liefert 204 mit `Access-Control-Allow-Origin`/`-Methods`/`-Headers` |
+| 3 | Fetch von nicht konfiguriertem Origin bleibt blockiert (kein Wildcard-Leck) | **bestanden** – `TestCORS_UnconfiguredOriginGetsNoAccessControlHeader`; real auf 131: `curl -H 'Origin: http://boesartige-seite.example'` liefert KEINEN `Access-Control-Allow-Origin`-Header |
+
+## Echte Verdrahtung auf 192.168.1.131
+
+- `retention-api` neu gebaut, `/etc/nexarch/archive-retention-api.env`
+  um `NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN=http://127.0.0.1:3099`
+  ergänzt (RET-06-Dev-Server-Origin), Dienst neugestartet.
+- Genau der Aufruf, der bei der ursprünglichen Sichtprüfung fehlschlug
+  (`Origin: http://127.0.0.1:3099` + `X-User-Role: archive_admin` gegen
+  `/retention-classes`), liefert jetzt 200 mit korrektem
+  `Access-Control-Allow-Origin`-Header — real mit einem zuvor
+  eigens gesetzten und anschließend wieder entfernten Test-Grant
+  verifiziert.
+
+## 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. retentionapi mit 3 neuen CORS-Tests)
+```
+
+## Gesamtergebnis
+
+**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
+Pflichtprüfungen real erfüllt. Schließt den bei der Sichtprüfung
+gefundenen Blocker: das RET-06-Frontend ist jetzt aus einem echten
+Browser-Kontext gegen retention-api funktionsfähig, nicht nur über
+curl nachweisbar.