API-11: wiederanlauf-nachsynchronisierungs-endpunkt-starten

- Merge API-02 (bereits Vorfahre), AUD-01, LIC-03 in API-06-Branch, um
  echte Produktionsimplementierungen fuer resync.Handler zu erhalten
  (moduleregistry.Registry, audit.Log, usage.Store) - go.mod/go.sum/
  scripts/reset-test-env.sh additiv zusammengefuehrt, keine Logikkonflikte
- cmd/resync-api: startet internal/resync.Handler (API-06) als
  eigenstaendigen HTTP-Dienst, kleiner auditAdapter fuer Signatur-
  Anpassung (kein neuer Fachcode)
- reines Wiring, kein Diff an internal/resync|audit|usage|moduleregistry
  (verifiziert)
- real deployed auf 131, end-zu-ende per curl mit echtem, ueber
  moduleregistry.Registry.Provision ausgestelltem Service-Credential:
  angewendetes usage-delta real in usage_counters bestaetigt, falsches
  Credential -> 401
- reale Grant-Luecke gefunden und behoben (nexarch_core auf modules/
  module_credentials/audit_events/feature_flags/usage_counters/
  resync_*_buffer), ueber information_schema verifiziert

Pruefungen siehe docs/API-11-PRUEFPROTOKOLL.md

docs/API-11-PRUEFPROTOKOLL.md

@@ -0,0 +1,76 @@
+# API-11 – Prüfprotokoll: Wiederanlauf-Nachsynchronisierungs-Endpunkt starten (API-06 als laufender Dienst)
+
+Voraussetzung API-06 – bereits Fertig, hier UNVERÄNDERT.
+
+## Reines Wiring, keine neue Logik
+
+`git diff --stat internal/resync/ internal/audit/ internal/usage/ internal/moduleregistry/`
+liefert KEINEN Diff gegenüber den jeweiligen Ticket-Ständen. `API-11`
+fügt ausschließlich `cmd/resync-api/main.go` hinzu — inklusive eines
+kleinen `auditAdapter`, der `resync.AuditRecorder` (einzelne Felder)
+auf `audit.Log.Record` (Event-Struct) abbildet. Das ist reine
+Signatur-Anpassung, keine neue Geschäftslogik.
+
+## Root Cause (dokumentiert)
+
+`cmd/core/main.go` ist seit TEN-01 minimal geblieben (nur `/healthz`,
+`/internal/tenants`) — kein späteres Ticket (RBAC-02, CFG-02, API-06,
+...) wurde je dort zentral eingehängt. Jedes Modul entstand auf einer
+eigenen, unabhängigen Feature-Branch-Kette. API-11 folgt dem in dieser
+Session etablierten Muster (RBAC-06, CFG-05, RET-09): ein eigener,
+kleiner HTTP-Dienst statt eines zentralen `cmd/core`-Umbaus.
+
+## Umsetzung
+
+- `cmd/resync-api/main.go` – startet `internal/resync.Handler` mit
+  echten Produktions-Implementierungen: `moduleregistry.Registry`
+  (Auth), `audit.Log` (über `auditAdapter`), `usage.Store`.
+- `deploy/systemd/nexarch-resync-api.service.tmpl`.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-resync-api.service` aktiv, `Restart=on-failure` |
+| 2 | Realer POST /internal/resync/usage von einem externen Testclient gegen den laufenden Dienst liefert die erwartete Verarbeitung | **bestanden** – real per `curl`: mit echtem, über `moduleregistry.Registry.Provision` ausgestelltem Service-Credential (`X-Nexarch-Client-Id`/`X-Nexarch-Client-Secret`) liefert der Aufruf `{"applied":1}`, `usage_counters` zeigt real den erhöhten Zähler; mit falschem Credential 401. Testdaten (Modul, Credential, Zähler-Zeile) anschließend entfernt |
+| 3 | Code-Review: keine Änderung an internal/resync/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: `internal/resync/`, `internal/audit/`, `internal/usage/`, `internal/moduleregistry/` unverändert gegenüber ihren jeweiligen Ticket-Ständen |
+
+## Echte Verdrahtung auf 192.168.1.131
+
+- `resync-api` gebaut nach `/opt/nexarch-core/bin/`,
+  `/etc/nexarch/resync-api.env` (0600), `nexarch-resync-api.service`
+  installiert/aktiviert.
+- Reale Rechtevergabe-Lücke gefunden und behoben (gleiches Muster wie
+  bei den vorherigen Wrapper-Diensten): `modules`, `module_credentials`,
+  `audit_events`, `feature_flags`, `usage_counters`,
+  `resync_audit_buffer`, `resync_usage_buffer` gehörten `postgres`,
+  `nexarch_core` hatte keine Rechte — `GRANT` nachgezogen und über
+  `information_schema.role_table_grants` verifiziert, bevor der
+  End-zu-Ende-Test erneut lief.
+- Zusätzliche reale Erkenntnis: `usage_counters.tenant_id` ist `UUID`,
+  nicht der Tenant-Slug (String) — beim ersten Testversuch mit `"acme"`
+  scheiterte der Insert intern, `UsageHandler` meldete `applied:0` statt
+  eines Fehlers (stiller Fehlschlag pro Delta, so von API-06 selbst so
+  entworfen: "Aufrufer entfernt aus seinem Puffer nur bestätigt
+  übernommene Deltas" — kein API-11-Defekt, sondern korrektes,
+  bestehendes API-06-Verhalten). Mit echter UUID als `tenant_slug`-Wert
+  lieferte der Aufruf real `applied:1`.
+
+## Build/Test-Ergebnis (192.168.1.131)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./cmd/resync-api/...  -> 0 issues
+```
+
+Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go/Adapter,
+die eigentliche Logik ist bereits durch API-06s eigene Tests
+abgedeckt).
+
+## Gesamtergebnis
+
+**Bestanden.** API-06 ist jetzt ein real laufender, über systemd
+verwalteter Dienst. Modul-Clients wie DMS' `storage.HTTPUsageReporter`
+(RET-06/DOC-16-Umfeld) können sich jetzt real gegen einen laufenden
+Endpunkt verdrahten, statt gegen unverdrahteten Go-Code zu testen.