docs(quick-260910-jab): Aktenstand kohaerent machen — Ledger, Klassifikation, Kritikschrift, Betriebsanleitung

- WINDOWS.md: #19 auf fixed gesetzt (Tabelle + JSON-Block), mit Beleg
  (Migrationsname + benannte Pruefungen) und ausdruecklicher Feststellung,
  dass die SearchProvider-Haelfte als widerlegte Praemisse schliesst, nicht
  als geloestes Problem. #18/#20/#21/#22/#23 bleiben unveraendert offen. Ein
  neuer Eintrag #24 haelt den fehlenden Verwaltungsweg fuer plattformweite
  Zeilen unter der Anwendungsrolle offen (verschwindet nicht mit #19). Die
  vier Kopfzahlen sind aus dem JSON-Block abgeleitet (6 offen, 17 behoben, 1
  zurueckgestellt, 24 gesamt).
- Klassifikation: #19-Block von offener Frage zu beantwortet, die
  Uebersichtszeile tenders (35/27) und Summenzeile (107/135) aus dem
  Quelltext neu abgeleitet, vier Bestandsaufnahme-Zeilen nachgezogen
  (searchProvider, groups.service.ts/user, module-grants.service.ts/
  moduleGrant, tender-rss-feed.service.ts/tenderRssFeedSource), der Punkt in
  "Was diese Etappe NICHT entscheidet" aufgeloest.
- Kritikschrift: neuer Abschnitt "Regelschluss T-JTS-02, T-JTS-03 und
  WINDOWS #19" mit tatsaechlich beobachteter Ausgabe, Regelliste der
  lebenden Datenbank, Signaltabelle mit beiden Fehlerrichtungen je Regel,
  der neuen Stelle aus Befund F, der selbst ausgefuehrten Messung zur
  fehlenden Benutzerdimension (keine zweite Sitzungsvariable gefunden) und
  dem, was dieser Durchlauf nicht loest/nicht anfasst. Fuenf ueberholte
  Bestandsstellen mit Nachtraegen versehen (g4, t4, die Signaltabellenzeile
  zu den RSS-Pfaden, drei aufgezeichnete Werkzeugausgaben, m4), die alten
  Messprotokolle bleiben woertlich stehen.
- Betriebsanleitung: die eine Stelle, die #19 als offen fuehrte, nennt jetzt
  den Aufloesungsstand und WINDOWS #24.

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

docs/mandantentrennung-datenbankrolle.md

@@ -87,8 +87,13 @@ Arbeitsvorrat fuer die Umstellung. **16** Paare betreffen keine
 mandantengebundene Tabelle (plattformweite Daten wie der Ausschreibungs- und
 Modulkatalog, D-03) und **3** sind bewusst uebergreifend mit ausgeschriebenem
 Grund. Zusaetzlich zu beachten: das entdeckte, aber in dieser Etappe nicht
-behobene `forTenant()`-Verbindungsproblem (WINDOWS #20, siehe unten) und
-WINDOWS #19 (nullbares `tenantId` bei `SearchProvider`/`TenderRssFeedSource`).
+behobene `forTenant()`-Verbindungsproblem (WINDOWS #20, siehe unten). WINDOWS
+#19 (nullbares `tenantId` bei `SearchProvider`/`TenderRssFeedSource`) ist
+GESCHLOSSEN (260910-jab, Migration
+`20260910120000_rls_widen_membership_grant_and_platform_read`) — siehe
+`docs/mandantentrennung-zugriffsklassifikation.md`, Abschnitt "Zwei belegte
+Befunde", und `.planning/WINDOWS.md`. Offen geblieben ist der Verwaltungsweg
+fuer plattformweite Zeilen unter der Anwendungsrolle (WINDOWS #24).
 
 Darunter war bis Aufgabe 2 dieser Etappe auch der Anmeldeweg selbst, der
 strukturell nicht anders funktionieren konnte: `apps/api/src/auth/auth.service.ts`