Gesamtprojekt: Pruefprotokoll Nachtrag (#105/#107/#106, Service-Token, Verifikation auf 204)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/GESAMTPROJEKT-PRUEFPROTOKOLL.md

@@ -91,3 +91,34 @@ Keine der vier INT-01-Lücken ist im zusammengeführten Core geschlossen:
 - `mail/` hat `go 1.24`, `archive/` `go 1.22`: Angleichung an Core/DMS (1.25) prüfen, insbesondere für `govulncheck`.
 - Die Bestandsprobleme der Core-Tests (Reihenfolge- und Zustandsabhängigkeit zwischen Paketen, `postgres`-Datenbankname und `postgresql://`-Präfix im Test) sollten mit einem Test-Ticket bereinigt werden (Isolation je Test, wie in DMS FDN-16).
 - Nicht ausgeführt: S3-, Backup- und Manticore-Tests, `soffice`, `clamd`.
+
+## 9. Nachtrag: #105, #107, #106 und Service-Token (Stand 2026-09-21)
+
+Ersetzt die Aussagen in Abschnitt 6 (Legal-Hold-Endpunkt fehlt), Abschnitt 7 (vier Vertragslücken offen) und die Punkte „cmp-02/06/07 portieren“ in Abschnitt 8.
+
+**Merges** (alle konfliktfrei, `--no-ff`): `8f97d50` #105 Archive-Alt-Linien (enthält #103 RET-03), `884eaeb` #107 RET-13 (`GET /legal-hold`), `9d38cb9` #106 Core↔DMS-Vertrag (API-14, API-15, RBAC-09).
+
+**Fix im DMS** (`2fb1716`, `03c5de8`): `retentionclient` sendet `X-Service-Token`, wenn `NEXARCH_DMS_APP_RETENTION_SERVICE_TOKEN` (App) bzw. `NEXARCH_DMS_WORKER_RETENTION_SERVICE_TOKEN` (Worker) gesetzt ist. Ohne Token unverändert. Der Token steht in keinem Fehlertext (Test). Dokumentiert in `dms/docs/BETRIEB-UMGEBUNGSVARIABLEN.md`. Der Archive-Dienst muss dann mit `NEXARCH_MODULEADAPTER_SERVICE_TOKEN` desselben Werts laufen, sonst antwortet er 401 und das DMS löscht nie (fail closed).
+
+**Migrationen** (`55b2673`, `scripts/migrations-fresh-check.sh`, frisch von null in Wegwerf-DBs auf 204): Core Registry 29, Core Mandant 17, DMS 32, Archive 15 (0001–0015, keine Doppelnummern), Mail (Postgres) 12. In der gemeinsamen Mandanten-DB (Core Mandant, DMS, Archive, Mail) entstehen 87 Tabellen ohne Kollision. Doppelte Nummern bleiben: Core Registry und Mandant, DMS `0016` ×3. Nichts umbenannt.
+
+**Prüfungen auf 204** (frische Klone des gepushten Branches, seriell, Sperre `runhost-locks-204`, Wegwerf-Cluster `17/coredev`, `archivdms`-Cluster nicht berührt):
+
+| Modul / Prüfung | Ergebnis |
+|---|---|
+| DMS `go test ./...` (mit `TEST_KOSIT_ADDR`) | 77 Pakete ok, 0 FAIL (Hauptlauf 71, abgeschnittener Kopf `cmd/…`, `internal/a*` separat: 6) |
+| DMS `go vet`, `gofmt` (geänderte Pakete) | sauber |
+| Archive `build`, `vet`, `gofmt`, `test -p 1` | sauber, 28 Pakete ok |
+| Core `build`, `vet`; Tests je Paket mit Cluster-Reset | 53 Pakete ok, 0 FAIL (72 Pakete, Rest ohne Tests) |
+| Mail `build`, `vet` | sauber |
+| Mail `test -p 1 ./...` | 35 ok, `indexworker`: 2 FAIL (`TestDequeue_WorkerCrashMidRunLosesNoJob`, `TestEnqueueAndStatus_RoundTrip`); identisch vor diesen Merges (Stand `55ae1fa`), allein `go test ./internal/indexworker/` PASS: Zustandsabhängigkeit zwischen Mail-Paketen in der gemeinsamen DB, Bestand |
+| Vertragstest Archive↔DMS `scripts/legalhold-contract-test.sh` ohne Token | bestanden |
+| Vertragstest mit Token (`LH_TOKEN`) | bestanden: ohne/falscher Token 401, fremder Mandant 403, richtiger Mandant 200, 503 bei Registry-Ausfall |
+| Ende-zu-Ende Core→DMS `scripts/e2e-core-dms.sh` | 8/8 Teilfälle, 42,9 s |
+| `check-port-defaults.sh`, `check-route-prefixes.sh` | ok |
+
+Fix-Iterationen: 1 (Testfehler im neuen Vertragstest: Fremd-Mandanten-Client sendete keinen Token, 401 statt 403), 0 im Produktivcode. `gofmt`: 13 Core-Dateien und 4 Mail-Dateien unformatiert (Bestand, keine geänderte Datei).
+
+**Vertragslücken Core↔DMS:** (1) JWKS-Route, (2) Rolle im Modul-JWT, (3) `dms.*`-Rechte, (4) `GET /legal-hold` sind geschlossen (siehe PR #106, #107). Weiter offen: Mandant und Modulaktivierung in `POST /authorize` (Ticketvorschlag RBAC-10), persistente Modul-Schlüssel (API-16), Token-Widerruf, Oberflächen im Token-Modus (Login → Bearer), Reverse-Proxy-Regel für die JWKS-Route, DMS-Entscheidung zu `registered:false`, Testisolation der Mail-Pakete (Zustand in der gemeinsamen DB), Core-Testisolation.
+
+**Zu beachten:** `core-cluster.sh` ist jetzt gegen versehentliches Stoppen abgesichert (`stop` ist ein No-Op, `FORCE=1` erzwingt), `reset`/`resettenant` sind nur innerhalb der Sperre `runhost-locks-204` zu verwenden.