docs(quick-260909-mir): Etappe 2 Bereich dkv abgeschlossen, zwei Doku-Luecken behoben

docs/mandantentrennung-zugriffsklassifikation.md

@@ -139,11 +139,13 @@ exakte Praezedenzfall aus `ldapConfig` in 260909-ipc.
 | bewusst-uebergreifend | 3 |
 | **Summe** | **62** |
 
-## Der Hintergrunddienst als Falle — drei `beides`-Fälle
+## Der Hintergrunddienst als Falle — vier Fälle
 
 Ein Planer, der über alle Mandanten iteriert, liest zu Recht übergreifend —
-muss aber *innerhalb* der Schleife je Mandant binden. Drei Dateien sind
-betroffen:
+muss aber *innerhalb* der Schleife je Mandant binden. Drei Dateien sind in
+diesem Sinne `beides`-Fälle; der vierte, seit 260909-mir bekannte Fall ist von
+anderer Art und deshalb unten getrennt aufgeführt — er iteriert gar nicht,
+sondern greift sich eine beliebige Zeile heraus:
 
 - **`ldap.service.ts`** (AD-Abgleich) — **Stand 260909-ipc, Aufgaben 2/3:
   geschlossen.** Iteriert nicht selbst über alle Mandanten (der Sync läuft
@@ -193,6 +195,30 @@ betroffen:
   `forTenant()`, EIN gebundener Client je Profil, gebunden an dessen
   Mandanten.
 
+**Der vierte Fall, anderer Bauart — `dkv-scheduler.service.ts` /
+`DkvService.loadAnyActiveConfigForScheduler()`** (260909-mir, Befund D,
+WINDOWS #21): **offen, als benannte Altlast weitergeführt.** Dieser Dienst
+gehört nicht in dieselbe Klasse wie die drei oben. Jene lesen bewusst über alle
+Mandanten und müssen lediglich innerhalb der Schleife binden — sie sind heute
+korrekt und verstummen erst nach dem Scharfschalten. Der DKV-Planer iteriert
+überhaupt nicht: `findFirst()` ohne jede Bedingung zieht bei mehreren Mandanten
+EINEN beliebigen und bedient die übrigen NIE. Ist ausgerechnet die gezogene
+Zeile inaktiv, bedient er niemanden, obwohl ein zweiter Mandant aktiv wäre. Er
+ist damit **heute bereits falsch** und verstummt nach dem Scharfschalten
+zusätzlich (`null` statt einer beliebigen Zeile; der Planer protokolliert das als
+Normalfall und richtet für JEDEN Mandanten nichts ein, ohne Alarm).
+
+Binden ist hier keine Lösung: `onModuleInit()` hat beim Start strukturell keinen
+Mandantenkontext, ein gebundener Aufruf liefe garantiert leer. Der Umbau auf
+einmal-abfragen-viele-bedienen ist die in Phase 07-04 zurückgestellte
+Mehrmandanten-Planung — eine Funktionsänderung, kein Bindungsumbau, und deshalb
+in Etappe 2 nicht vorgenommen. Der Zugriff bleibt deshalb ungebunden, aber
+dreifach markiert: eigene benannte Methode mit Kopfkommentar (bewusst KEINE
+Verzweigung hinter einem optionalen Parameter, die jemand später
+„vereinheitlicht"), fortgeschriebener Kopfkommentar in
+`dkv-scheduler.service.ts`, Ledger-Eintrag WINDOWS #21. Das Signal für das
+Verstummen gehört in die Vorabprüfung von Etappe 4 (`rls-preflight.mjs`).
+
 ## Bestandsaufnahme
 
 Maschinell ermittelt, `rls-access-inventory.spec.ts` hält Vollständigkeit