docs(quick-260911-mkj): Abschnitte abgeleitet, WINDOWS #27 geschlossen, Restmenge als eigener Eintrag

- Klassifikationsdokument: Klassen-Verteilung (35/21/14/2, 72 Paare),
  Uebersichtsabsatz (zweite methodische Luecke, geschlossen) und
  Hintergrunddienst-Nachtrag (ldap/getAllActiveConfigs reicht auch in
  LdapFieldMapping hinein) aus Tabelle/Greps abgeleitet, nicht abgeschrieben
- Kritikschrift: Nachtrag (260911-mkj) unter (n4) im Bereich tenant, Vermerk
  im Etappe-2-Abschluss dass #27 geschlossen ist
- WINDOWS.md: #27 fixed (Nachweis: vierte Erkennungsform, Proben,
  Zwischenmessung 7/3/1); neuer Eintrag #33 fuer die Empfaenger ausserhalb
  der vier Erkennungsformen (tenders.seed.ts, backfill-tender-source.ts)
- Spec: WINDOWS #TBD-MKJ-Platzhalter durch #33 ersetzt

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

docs/mandantentrennung-etappe2-fehlerrichtung.md

@@ -2471,6 +2471,28 @@ Mandantenzahl belanglos, dieselbe Form wie
 Wartungsrolle gegen die gebundene Fan-out-Zaehlung ist dieselbe Pruefung wie
 im Bereich `user` — kein eigener Eintrag noetig.
 
+**Nachtrag (260911-mkj):** WINDOWS #27 — die in (b) beschriebene
+Erkennungsluecke der Bestandsaufnahme — ist geschlossen. Eine vierte
+Erkennungsform in `rls-access-inventory.spec.ts` (`analyzeSource`,
+`SCHEMA_RELATIONS`) loest Relationsfelder ueber `schema.prisma` auf ihr
+Zielmodell auf und traegt das Zielmodell als eigene Fundstelle ein — der
+Nachweis steht gegen KONTROLLIERTE Proben im Spec, nicht gegen die drei
+realen Stellen aus (b): die einzige gefaehrliche Auspraegung
+(`tenant.controller.ts`, ungebundener aeusserer Aufruf auf ungeschuetzter
+Tabelle mit Einbindung in eine geschuetzte Tabelle) traegt die Form seit
+(n3)/Aufgabe 3 (dem Fan-out-Ersatz) nicht mehr — deshalb Probestrings, die
+dieselbe Form nachbilden (ungebunden und gebunden). Gemessen: SIEBEN neue
+(Datei, Modell)-Paare, DREI fortgeschriebene Staende, davon
+`ldap-config.service.ts`/`ldapFieldMapping` als einziger Klassenwechsel
+(`muss-mandantengebunden` -> `beides`, siehe (b) oben: `getAllActiveConfigs`
+reicht auch in `LdapFieldMapping` hinein, nicht nur in `Tenant`). Verbleibende
+Grenze, LAUT gehalten statt still: ein Empfaenger ausserhalb aller vier
+Erkennungsformen bleibt fuer JEDE Form unsichtbar — gemessen
+`tenders/tenders.seed.ts` (Funktionsparameter `prisma: PrismaService`) und
+`tenders/backfill-tender-source.ts` (eigenstaendiges Skript, eigener `new
+PrismaClient()`), beide als eigener Ledger-Eintrag gefuehrt (nicht
+stillschweigend mit #27 mitgeschlossen).
+
 ### (n5) Was dieser Durchlauf bewusst nicht anfasst
 
 - Der direkte Prisma-Zugriff im Controller (Muster wie `user.controller.ts`)
@@ -3072,7 +3094,8 @@ Bedingung gebunden wie #18), #21 (dkv-Planer-Startpfad), #22
 (module-registry, unterscheidbares Signal fehlt), #24 (plattformweite
 RSS-Verwaltung unter der Anwendungsrolle), #25 (dashboard, beweisvernichtende
 Fehlerrichtung), #26 (calendar, verschluckte Leere), #27
-(Relationszugriffe für die Bestandsaufnahme unsichtbar), #28 (auth,
+(Relationszugriffe für die Bestandsaufnahme unsichtbar, seit 260911-mkj
+geschlossen), #28 (auth,
 verschluckte Leere), plus die drei neuen Einträge dieses Laufs (Startpfad
 des Mailmoduls, verschluckte Leere `favorites`, verschluckte Leere
 `settings` — Nummern siehe Aufgabe 3 dieses Plans).