feat(quick-260909-ipc): ldap.service.ts an forTenant() binden, Adress-Kollisionspruefung bewusst uebergreifend belassen

Aufgabe 3 der Etappe 2: elf Abfragen in sechs Methoden (listGroups,
upsertMappedUser, searchUsers, importUsersByDn, importGroupsByDn,
syncUsersForTenant) laufen jetzt ueber forTenant(), teils mit einem neu
erzeugten, teils mit dem in derselben Methode bereits vorhandenen gebundenen
Client. resolveEmailForWrite bleibt ausdruecklich ungebunden (Befund A,
T-IPC-04): email/username sind plattformweit eindeutig, eine Bindung wuerde
einen fremden Halter uebersehen und eine saubere Kollisionsmeldung in einen
P2002-Abbruch verwandeln.

Ein neuer Testblock biegt forTenant() auf ein zweites, unterscheidbares
Client-Objekt um (der bisherige Identitaets-Mock haette die Umstellung nicht
bemerkt, Befund F) und belegt damit, dass die Adressabfrage weiterhin am
ungebundenen und der Rest am gebundenen Client landet. Alle 67 Bestandstests
bleiben unveraendert gruen.

docs/mandantentrennung-zugriffsklassifikation.md ist fuer den Bereich ldap
geschlossen: gemessener Stand je Fundstelle, neu gerechnete Bereichsuebersicht
(gebunden getrennt von ungebunden gezaehlt) und die Uebergabe des
Standardgruppen-Punkts an den Bereich groups vor Etappe 4 dokumentiert.

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

docs/mandantentrennung-zugriffsklassifikation.md

@@ -63,26 +63,40 @@ Fundstellen gelöst werden: die Policy braucht für den Lesezugriff
 `tenantId IS NULL OR tenantId = current_tenant_id()`, während Schreibzugriffe
 weiterhin einen Mandanten verlangen.
 
-## Übersicht je Bereich (Zeilentreffer, `this.prisma.*` ohne Specs)
+## Übersicht je Bereich (Zeilentreffer je Bereich, ungebunden vs. gebunden)
 
-Gemessen mit `grep -ro "this\.prisma\.[a-zA-Z]*" apps/api/src/<bereich> | grep -v spec | wc -l`
-am 2026-09-09, **nach** den Änderungen aus Aufgabe 1/2 dieses Plans:
+**Wichtig, seit 260909-ipc (Aufgabe 3):** die Spalte "Ungebunden" zählt NUR
+noch `this.prisma.<Modell>`-Rohtreffer — eine unveränderte Spaltenüberschrift
+über einer veränderten Bedeutung wäre die nächste stille Falle, seit ein
+Bereich (`ldap`) tatsächlich gebundene Zugriffe hat, die aus dieser Zählung
+verschwinden. Die neue Spalte "Gebunden" zählt daneben die
+`forTenant()`-gebundenen Rohtreffer (`tenantPrisma.<Modell>`, Konvention
+dieses Codes — siehe `rls-access-inventory.spec.ts` für die allgemeinere,
+namensunabhängige Erkennung über die `const <Name> = forTenant(`-Zuweisungsform).
+Beide Spalten sind Rohtreffer (mehrere Vorkommen desselben Modells in
+derselben Datei zählen mehrfach), nicht (Datei, Modell)-Paare wie in der
+Bestandsaufnahme unten.
 
-| Bereich | Treffer | Hinweis |
-|---|---|---|
-| tenders | 62 | unverändert gegenüber measured_baseline |
-| groups | 37 | unverändert |
-| ldap | 21 | unverändert |
-| dkv | 21 | unverändert |
-| user | 17 | unverändert |
-| module-registry | 17 | unverändert |
-| dashboard | 13 | unverändert |
-| auth | 8 | **war 13 in measured_baseline** — Aufgabe 2 hat 3 Lesezugriffe durch `auth_lookup_*()`-Funktionsaufrufe (`$queryRaw`, kein `this.prisma.<Modell>`) ersetzt und 5 Schreibzugriffe auf `forTenant()`-gebundene Aufrufe (`tenantPrisma.*`, ebenfalls kein `this.prisma.<Modell>`) umgestellt |
-| calendar | 12 | unverändert |
-| tenant | 8 | unverändert |
-| favorites | 7 | unverändert |
-| settings | 4 | unverändert |
-| **Summe** | **227** | war 232 in measured_baseline, Delta = die 5 in Aufgabe 2 verschwundenen `auth`-Treffer minus ein bereits vorher fehlerhaft mitgezähltes Kommentarvorkommen in der neuen Kopfzeile von `validateUser()`, das bewusst umformuliert wurde, um einen Eigentreffer der Bestandsaufnahme-Prüfung zu vermeiden |
+Gemessen mit
+`grep -ro "this\.prisma\.[a-zA-Z]*" apps/api/src/<bereich> | grep -v spec | wc -l`
+bzw. `grep -ro "tenantPrisma\.[a-zA-Z]*\." apps/api/src/<bereich> | grep -v spec | wc -l`
+am 2026-09-09, **nach** den Änderungen aus Aufgabe 2/3 dieses Plans (260909-ipc):
+
+| Bereich | Ungebunden | Gebunden | Hinweis |
+|---|---|---|---|
+| tenders | 62 | 0 | unverändert |
+| groups | 37 | 0 | unverändert |
+| ldap | 4 | 26 | **war 21/0** — Aufgabe 2/3 (260909-ipc) haben `ldap-config.service.ts` (5 Methoden) und `ldap.service.ts` (6 Methoden, 11 Abfragen) auf `forTenant()` umgestellt. Die 4 verbleibenden ungebundenen Treffer sind bewusst: `getAllActiveConfigs`/`onApplicationBootstrap` (Befund B) und `resolveEmailForWrite` (Befund A, T-IPC-04) |
+| dkv | 21 | 0 | unverändert |
+| user | 17 | 0 | unverändert |
+| module-registry | 17 | 0 | unverändert |
+| dashboard | 13 | 0 | unverändert |
+| auth | 8 | 5 | unverändert gegenüber dem in Etappe 1 (260909-eor) gemessenen Stand |
+| calendar | 12 | 0 | unverändert |
+| tenant | 8 | 0 | unverändert |
+| favorites | 7 | 0 | unverändert |
+| settings | 4 | 0 | unverändert |
+| **Summe** | **210** | **31** | Ungebunden: war 227 vor dieser Etappe (260909-eor-Stand), Delta = die 17 in Aufgabe 2/3 umgestellten `ldap`-Rohtreffer. Gebunden: war 5 (nur `auth`), jetzt zusätzlich 26 in `ldap` |
 
 ## Klassen-Verteilung (nach (Datei, Modell)-Fundstellen, 61 Paare)
 
@@ -109,15 +123,27 @@ Ein Planer, der über alle Mandanten iteriert, liest zu Recht übergreifend —
 muss aber *innerhalb* der Schleife je Mandant binden. Drei Dateien sind
 betroffen:
 
-- **`ldap.service.ts`** (AD-Abgleich): iteriert nicht selbst über alle
-  Mandanten (der Sync läuft je Aufruf für einen übergebenen Mandanten), aber
-  innerhalb der Sync-Methoden bleiben Lesezugriffe auf `group`, `ldapConfig`
-  und `user` teils ungebunden, obwohl der Mandant zu diesem Zeitpunkt bereits
-  bekannt ist — die 4 echten `forTenant()`-Aufrufstellen (Zeilen 762, 905,
-  1179, 1342) decken nur einen Teil der Lese-/Schreibpfade ab. Das ist der im
-  Plankontext benannte Kern von WINDOWS #20: genau dieser Löschzweig
-  (~Zeile 1559) deutet Leere nach dem Scharfschalten als "Gruppe im
-  Verzeichnis verschwunden".
+- **`ldap.service.ts`** (AD-Abgleich) — **Stand 260909-ipc, Aufgaben 2/3:
+  geschlossen.** Iteriert nicht selbst über alle Mandanten (der Sync läuft
+  je Aufruf für einen übergebenen Mandanten). Vor dieser Etappe blieben
+  Lesezugriffe auf `group`, `ldapConfig` und `user` innerhalb der
+  Sync-Methoden teils ungebunden, obwohl der Mandant zu diesem Zeitpunkt
+  bereits bekannt war — nur 4 der inzwischen 11 `forTenant()`-Aufrufstellen
+  deckten die Lese-/Schreibpfade ab. Jetzt sind `group` und `ldapConfig`
+  vollständig gebunden; bei `user` bleibt ausschließlich
+  `resolveEmailForWrite` bewusst ungebunden (Befund A, T-IPC-04 — siehe
+  Bestandsaufnahme unten). Der als gefährlichster Punkt benannte
+  Löschzweig (`syncBoundGroupsForTenant`, WINDOWS #20) war bereits seit
+  Etappe 1 gebunden. Offen bleibt eine Reihenfolgebedingung für Etappe 4,
+  NICHT Teil dieser Umstellung: die Übergabe unmittelbar vor der Löschung —
+  `this.groupsService.reassignDefaultBeforeDelete(tenantId, group.id)` und
+  `ensureDefaultGroup(tenantId)` — liegt in `groups.service.ts` und ist
+  nicht gebunden. Nach dem Scharfschalten würde `reassignDefaultBeforeDelete`
+  still `false` melden (kein Ersatzkandidat sichtbar), der Standard-Marker
+  wandert nicht mit, und der Mandant bliebe nach einer Gruppenlöschung ohne
+  Standardgruppe zurück — der Bereich `groups` muss deshalb vor Etappe 4
+  umgestellt sein (siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`,
+  Abschnitt (e), Befund D).
 - **`tender-digest.scheduler.ts`** (Ausschreibungs-Digest): liest
   `tenderMatch`/`tenderNotificationPref`/`user` bewusst über ALLE Mandanten
   in einem `findMany` (ein einziger globaler Cron-Job, kein Mandant im
@@ -161,10 +187,10 @@ verwendet), Klasse, Stand (`gebunden`/`ungebunden`/`gemischt`, seit
 | apps/api/src/groups/module-grants.service.ts | user | muss-mandantengebunden | ungebunden | Zielbenutzer eines Grants innerhalb des Mandanten. |
 | apps/api/src/ldap/ldap-config.service.ts | ldapConfig | beides | gemischt | `getConfig`, `createConfig` und `updateConfig` laufen ueber `forTenant()`, gebunden an den aus der Anfrage bereits bekannten Mandanten. `getAllActiveConfigs()` (Planer-Lesezugriff ueber ALLE Mandanten) und die Start-Nachverschluesselung in `onApplicationBootstrap` bleiben bewusst uebergreifend: beide laufen, bevor bzw. unabhaengig davon, ob ein einzelner Mandantenkontext feststeht (Befund B, 260909-ipc-PLAN.md). Korrektur der Klasse von `muss-mandantengebunden`: das Paar ist tatsaechlich `beides`, keine Verhaltensaenderung. |
 | apps/api/src/ldap/ldap-config.service.ts | ldapFieldMapping | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS ueber Join auf `LdapConfig`. `addFieldMapping` und `removeFieldMapping` nehmen den Mandanten jetzt als Parameter entgegen und laufen vollstaendig ueber `forTenant()` (T-IPC-01, 260909-ipc-PLAN.md) — schliesst zugleich die Fremdzugriffsluecke beim Loeschen einer Feldzuordnung ueber ihre Kennung. |
-| apps/api/src/ldap/ldap.service.ts | group | beides | gemischt | AD-Abgleich: 4 echte `forTenant()`-Aufrufstellen decken einen Teil ab, weitere `this.prisma.group`-Zugriffe innerhalb der Sync-Methoden bleiben ungebunden, obwohl der Mandant zu diesem Zeitpunkt bekannt ist (siehe Abschnitt "Der Hintergrunddienst als Falle"). |
+| apps/api/src/ldap/ldap.service.ts | group | beides | gebunden | AD-Abgleich: `listGroups` (die "bereits importiert"-Markierung) und `importGroupsByDn` (die Idempotenzpruefung ueber `ldapObjectGuid`) sind mit Aufgabe 3 (260909-ipc) auf `forTenant()` umgestellt — zusammen mit den bereits vorher gebundenen Stellen (Anlage, Mitgliedschafts- und Gruppenabgleich) ist damit jeder `group`-Zugriff dieser Datei gebunden. Die Klasse bleibt `beides`, weil ein zukuenftiger uebergreifender Lesezugriff (z. B. ein neuer Planer-Pfad) hier ebenso legitim waere wie bei `ldapConfig` unten — nicht, weil heute noch ein ungebundener Zugriff bestuende. |
 | apps/api/src/ldap/ldap.service.ts | groupMembership | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS ueber Join auf `Group`. `syncGroupMembershipsForTenant` laeuft vollstaendig ueber `forTenant()` (Plan 16-03/16-05) — von der alten, nur `this.prisma.*` erkennenden Suche nie erfasst, weil bereits gebunden; die erweiterte Erkennung aus Aufgabe 2 (260909-ipc) macht diese Fundstelle erstmals sichtbar. |
-| apps/api/src/ldap/ldap.service.ts | ldapConfig | beides | ungebunden | Dieselbe Begründung wie `group` — Konfigurationszugriffe innerhalb der Sync-Methoden. |
-| apps/api/src/ldap/ldap.service.ts | user | beides | gemischt | Dieselbe Begründung — der Löschzweig um Zeile 1559 (WINDOWS #20) ist der konkrete Risikofall. |
+| apps/api/src/ldap/ldap.service.ts | ldapConfig | beides | gebunden | Die `lastSyncAt`-Fortschreibung am Ende von `syncUsersForTenant` ist mit Aufgabe 3 (260909-ipc) auf den in derselben Methode bereits vorhandenen `forTenant()`-Client umgestellt — es entsteht kein zweiter. Damit ist der einzige `ldapConfig`-Zugriff dieser Datei gebunden. |
+| apps/api/src/ldap/ldap.service.ts | user | beides | gemischt | Mit Aufgabe 3 (260909-ipc) sind `upsertMappedUser` (Identitaetssuche und Aktualisierung), `searchUsers` (die "bereits importiert"-Markierung), `importUsersByDn` (Dedup und ldapDn-Nachtrag) und die Deaktivierungsschleife in `syncUsersForTenant` auf `forTenant()` umgestellt. `resolveEmailForWrite` bleibt ausdruecklich UNGEBUNDEN (Befund A, T-IPC-04): `email`/`username` sind plattformweit eindeutig, eine mandantengebundene Suche saehe einen fremden Halter nicht mehr und meldete faelschlich "frei" — die geloeste Klasse waere `muss-mandantengebunden` gewesen, bleibt wegen dieser einen bewusst uebergreifenden Abfrage `beides`. Der Loeschzweig um `syncBoundGroupsForTenant` (WINDOWS #20) ist bereits seit Etappe 1 gebunden und war nie Teil dieses Befunds. |
 | apps/api/src/module-registry/module-access.service.ts | module | keine-mandantengebundene-tabelle | ungebunden | Modulkatalog ist plattformweit, kein `tenantId`. |
 | apps/api/src/module-registry/module-access.service.ts | moduleGrant | muss-mandantengebunden | ungebunden | Modulfreigaben je Mandant. |
 | apps/api/src/module-registry/module-access.service.ts | tenantModuleActivation | muss-mandantengebunden | ungebunden | Aktivierung je Mandant, `tenantId`-Spalte vorhanden. |
@@ -204,7 +230,12 @@ verwendet), Klasse, Stand (`gebunden`/`ungebunden`/`gemischt`, seit
 ## Was diese Etappe NICHT entscheidet
 
 - Ob Controller künftig über `req.tenantPrisma` statt eines erneuten
-  `forTenant()`-Aufrufs im Service gehen (offener Befund oben).
+  `forTenant()`-Aufrufs im Service gehen (offener Befund oben). Der Bereich
+  `ldap` (260909-ipc) hat sich für den Dienst-internen Weg entschieden —
+  `forTenant(this.prisma, tenantId)` wird in jeder umgestellten Methode neu
+  erzeugt, wie es die vier Bestandsstellen in `ldap.service.ts` und die drei
+  in `auth.service.ts` bereits vormachten. Die Frage bleibt für alle
+  übrigen Bereiche der Etappe 2 offen.
 - Wie die WINDOWS-#19-Policy für `SearchProvider`/`TenderRssFeedSource`
   am Ende genau lautet — nur, dass sie vor dem Scharfschalten gelöst sein
   muss.