API-02: modul-registry-aktivierungspruefung

internal/moduleregistry: Registry.Register traegt Fachmodule mit Name,
Version und benoetigten Feature-Flags ein (Akzeptanzkriterium 1), fehlende
Pflichtangaben werden abgewiesen. IsActive kombiniert Registrierung + LIC-02
Feature-Flag-Auswertung (ALLE benoetigten Flags muessen fuer den Tenant
aktiv sein) — ein nicht registriertes Modul ist nie aktiv. List liefert alle
Module fuer Statusseite/Lizenzoberflaeche (Akzeptanzkriterium 3).

RequireActiveModule ist die zentrale Durchsetzungs-Middleware (Casbin-
Prinzip): weist Anfragen an ein deaktiviertes Modul ab, BEVOR der
Modul-Handler ueberhaupt aufgerufen wird (Akzeptanzkriterium 2) —
Pruefung per Test belegt, dass der Handler bei Deaktivierung nachweislich
nicht erreicht wird.

Service-Credentials (Akzeptanzkriterium 4): Registry.Provision stellt pro
Modul-Instanz Client-ID + Secret aus, gespeichert wird nur der SHA-256-Hash
des Secrets. Registry.Authenticate vergleicht timing-safe (dieselbe
subtle.ConstantTimeCompare-Referenzimplementierung wie AUD-02).
RequireServiceCredential-Middleware liest X-Client-Id/X-Client-Secret und
weist Aufrufe ohne gueltiges Credential mit 401 ab, bevor der Core-seitige
Endpunkt (z.B. Audit-Nachlieferung, Nutzungsmeldung) erreicht wird.

Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Anfrage an deaktiviertes Modul nachweislich vor Modul-Logik abgewiesen —
   TestRequireActiveModule_BlocksBeforeHandler: handlerReached bleibt false
   bei 403, wird true erst nach Aktivierung bei 200. PASS.
2. Registrierung mit fehlenden Pflichtangaben abgewiesen —
   TestRegister_RejectsMissingFields (leerer Name, leere Version). PASS.
3. Registry-Abfrage liefert konsistente Daten nach Aktivierung/Deaktivierung —
   TestIsActive_ReflectsFlagStateConsistently: aus/an/aus-Zyklus, IsActive
   folgt dem Flag-Zustand korrekt. PASS.
4. Aufruf mit ungueltigem/fehlendem Service-Credential abgewiesen, mit
   gueltigem angenommen — TestRequireServiceCredential_RejectsInvalidAcceptsValid
   und TestProvisionAndAuthenticate (falsches Secret, unbekannte Client-ID,
   korrektes Credential). PASS.

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

internal/moduleregistry/middleware.go

@@ -0,0 +1,46 @@
+package moduleregistry
+
+import "net/http"
+
+// RequireActiveModule weist Anfragen an ein nicht aktiviertes Modul ZENTRAL
+// ab, bevor der eigentliche Modul-Handler erreicht wird (Akzeptanzkriterium 2 /
+// Pruefung 1) — Casbin-Prinzip: Durchsetzung als Middleware statt verstreuter
+// Pruefungen in jedem Handler. tenantSlug/moduleName werden hier ueber
+// Query-Parameter gelesen (echte Extraktion aus JWT/Tenant-Kontext ist
+// API-05/TEN-06, nicht Teil dieser Kachel).
+func (r *Registry) RequireActiveModule(moduleName string, next http.HandlerFunc) http.HandlerFunc {
+	return func(w http.ResponseWriter, req *http.Request) {
+		tenantSlug := req.URL.Query().Get("tenant")
+		active, err := r.IsActive(req.Context(), tenantSlug, moduleName)
+		if err != nil {
+			http.Error(w, "aktivierungspruefung fehlgeschlagen", http.StatusInternalServerError)
+			return
+		}
+		if !active {
+			http.Error(w, "modul nicht aktiviert", http.StatusForbidden)
+			return
+		}
+		next(w, req)
+	}
+}
+
+// RequireServiceCredential authentifiziert eine Modul-Instanz ueber ihr
+// Service-Credential (X-Client-Id/X-Client-Secret-Header) BEVOR der
+// eigentliche Handler erreicht wird (Akzeptanzkriterium 4 / Pruefung 4).
+func (r *Registry) RequireServiceCredential(next http.HandlerFunc) http.HandlerFunc {
+	return func(w http.ResponseWriter, req *http.Request) {
+		clientID := req.Header.Get("X-Client-Id")
+		secret := req.Header.Get("X-Client-Secret")
+
+		_, ok, err := r.Authenticate(req.Context(), clientID, secret)
+		if err != nil {
+			http.Error(w, "authentifizierung fehlgeschlagen", http.StatusInternalServerError)
+			return
+		}
+		if !ok {
+			http.Error(w, ErrInvalidCredential.Error(), http.StatusUnauthorized)
+			return
+		}
+		next(w, req)
+	}
+}