feat(jts-03): module-grants.service.ts binden, beide Dokumente schliessen

Alle fuenf Methoden von ModuleGrantsService (assertTargetBelongsToTenant,
grant, revoke, getMatrix, getUserAccess) laufen jetzt ueber forTenant(); bei
den beiden Datenlieferungen teilen sich alle parallel abgesetzten
Teilabfragen denselben gebundenen Client. Die Mandanten-Gegenpruefung vor
jedem Erteilen bleibt ausdruecklich bestehen und bekommt einen Verweis auf
Befund F/T-JTS-03: die Regel auf ModuleGrant prueft nur die
Mandantenkennung der Zeile, nicht die referenzierte Gruppe. Der veraltete
Kommentar ueber der Mitgliedschaftsabfrage im Benutzer-Detail ("kein
forTenant hier") ist durch den neuen Stand ersetzt.

module-grants.service.spec.ts bekommt denselben Bindungsnachweis-Mock wie
groups.service.spec.ts (zwei unterscheidbare Clients ueber demselben
Speicher) und sechs neue Bindungsnachweise; alle 28 Bestandstests bleiben
gruen.

Beide Dokumente geschlossen: die Bereichsuebersicht fuer groups ist neu
gemessen (0 ungebunden, 31 gebunden — ein dokumentierter methodischer
Bodensatz, da die einfache Rohtrefferzaehlung die neun ueber `tx` gebundenen
Zugriffe innerhalb der drei Transaktionen nicht sieht), die
Klassen-Verteilung auf 62 Paare aktualisiert, und der als offen gefuehrte
Befund D aus dem ldap-Abschnitt der Fehlerrichtung ist mit Verweis auf
diesen Durchlauf als erledigt vermerkt (Nachtrag, nicht Neuschrieb). 743
Tests und die Typpruefung gruen; Schema, Migrationen und alle vier
Compose-Dateien unveraendert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR

docs/mandantentrennung-etappe2-fehlerrichtung.md

@@ -146,6 +146,15 @@ interpretieren:
   ohne Standardgruppe zurück. `groups` ist ohnehin als nächster Bereich der
   Etappe 2 vorgesehen.
 
+  **Nachtrag (260909-jts, Aufgabe 3): GESCHLOSSEN.** Der Bereich `groups`
+  ist umgestellt — `reassignDefaultBeforeDelete` und `ensureDefaultGroup`
+  laufen seit Aufgabe 2 dieses Plans vollständig über `forTenant()` bzw.
+  `withTenantTransaction()` (siehe Abschnitt "Bereich groups" unten und
+  `docs/mandantentrennung-zugriffsklassifikation.md`, Zeile
+  `groups.service.ts`/`group`, Stand `gebunden`). Die Reihenfolgebedingung
+  für Etappe 4 ist damit erfüllt. Der Befund oben bleibt unverändert stehen
+  — er beschreibt korrekt den Zustand zum Zeitpunkt der ldap-Umstellung.
+
 - **Die offene Architekturfrage `req.tenantPrisma`.** `tenant.middleware.ts`
   und `tenant.guard.ts` setzen `req.tenantPrisma = forTenant(...)`, aber
   kein Controller liest diesen Wert je. Dieser Durchlauf entscheidet NICHT,