docs(quick-260911-nke): Aktenstand kohaerent — Regelschluss Benutzerdimension, Nachtraege, Ledger

- Neuer Abschnitt "Regelschluss Benutzerdimension (Etappe 3b, 260911-nke)"
  in der Kritikschrift mit b1 (woertliche Werkzeugausgabe + pg_policies-Liste),
  b2 (Signaltabelle beide Fehlerrichtungen), b3 (NotFound-statt-Forbidden
  je Methode), b4/b5 (bewusst nicht geloest/angefasst). Zehn datierte
  Nachtraege an allen Stellen, die zuvor "keine Benutzerdimension" als
  Stand beschrieben (t1/t4/r4/w1/w4/k1/k4/f1/f4/Abschluss) — historische
  Messung bleibt lesbar.
- Klassifikation: drei Bestandsaufnahme-Zeilen (calendarSource,
  widgetInstance, favoriteLink) mit Zusatz "Benutzerdimension seit
  20260911120000 (260911-nke)"; neuer Punkt "Aufgelöst (260911-nke)" im
  Abschnitt "Was diese Etappe NICHT entscheidet"; neuer Stand-Absatz —
  Paarzahl (72) und Klassen-Verteilung bleiben unveraendert.
- Betriebsanleitung: `forTenant(prisma, tenantId, userId?)` und die zehn/
  vier-Tabellen-Aufteilung nachgezogen.
- Datenbankrolle: neuer Absatz zu `app.current_user`/`current_user_id()`
  neben `app.current_tenant`; SECURITY-DEFINER-Kopfkommentare unangetastet.
- Auftrag: 3b als erledigt markiert (Migrationsname, sechs statt drei
  Umkehrungen, Endzahlen); 3a/3c unveraendert.
- WINDOWS.md: neuer Eintrag #34 (open, deviation) fuer die bewusst offene
  Flanke — Aufrufer ohne userId sieht den ganzen Mandanten, kein Waechter
  gebaut.
- Baseline: 1020/62 Tests, Typpruefung sauber, Werkzeug 203/203 bestanden.
  Erlaubnisliste gegen 8829999 eingehalten, schema.prisma/Compose/.env/3a
  unveraendert.

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

docs/anleitung-entwicklung.md

@@ -320,8 +320,20 @@ die vollständige, maschinell geprüfte Liste — von dort ableiten, nicht raten
 
 **Was ein Entwickler nie vergessen darf:** jeder Zugriff auf eine mandantengebundene Tabelle läuft
 dienst-intern über einen mit `forTenant()` gebundenen Klienten `tenantPrisma`
-(`apps/api/src/prisma/prisma-tenant.extension.ts`) — die zusätzlichen `where`-Filter über
-`userId` bleiben bestehen, wo die Regel selbst keine Benutzerdimension kennt (siehe
+(`apps/api/src/prisma/prisma-tenant.extension.ts`) — `forTenant(prisma, tenantId, userId?)`
+trägt seit Migration `20260911120000_rls_user_dimension_personal_tables` (Etappe 3b,
+260911-nke) einen optionalen dritten Parameter: zehn persönliche Tabellen
+(CalendarSource, DashboardLayout, FavoriteLink, SearchProvider,
+TenderEmailConfig, TenderNotificationPref, TenderRssFeedSource,
+TenderSavedSearch, TenderTriage, WidgetInstance) tragen die Benutzerdimension
+in der Regel (`current_user_id() IS NULL OR "userId" = current_user_id()`),
+vier Tabellen mit `userId`-Spalte aber ohne persönliche Daten
+(GroupMembership, ModuleGrant, PasswordResetToken, TenderMatch) nicht. Nur
+Nutzer-CRUD-Aufrufer setzen `userId`; Hintergrunddienste und Verwaltungswege
+rufen weiterhin ohne ihn — das macht die `IS NULL OR`-Form fuer sie
+wirkungslos, keine Verschlechterung. Die zusätzlichen `where`-Filter über
+`userId` im Anwendungscode bleiben in JEDEM Fall bestehen — zweites Netz,
+kein Ersatz (siehe
 `docs/mandantentrennung-etappe2-fehlerrichtung.md`). Bei den Tabellen ohne eigene `tenantId`
 (oben) filtert die Anwendung stattdessen — wo relevant — über den zutreffenden Bezug (z. B.
 plattformweiter Katalog, kein Mandantenfilter nötig); siehe