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/mandantentrennung-datenbankrolle.md

@@ -67,6 +67,24 @@ noetig sind:
   `20260909140000_rls_remaining_tenant_tables` ergaenzt die bislang
   fehlenden 16 Tabellen; alle 20 Tabellen mit `tenantId` tragen jetzt eine
   Regel.
+- **Eine zweite Sitzungsvariable fuer die Benutzerdimension.** Neben
+  `app.current_tenant` (Migration `20260618112133_rls_policies`,
+  `current_tenant_id()`) setzt die Rolle seit Migration
+  `20260911120000_rls_user_dimension_personal_tables` (Etappe 3b,
+  260911-nke) zusaetzlich `app.current_user`. Die zugehoerige Funktion
+  `current_user_id()` faltet den Leerstring per `NULLIF` auf `NULL` — der
+  Helfer `forTenant()` sendet "kein Benutzer" ausdruecklich als Leerstring,
+  nicht als weggelassene Variable, damit ein Aufruf ohne Benutzer nie einen
+  Benutzer aus einer fruaheren Transaktion derselben Verbindung erben kann.
+  Kein `GRANT EXECUTE` noetig — wie bei `current_tenant_id()` vergibt
+  PostgreSQL EXECUTE auf Funktionen standardmaessig an PUBLIC. Die Regeln
+  der zehn persoenlichen Tabellen (CalendarSource, DashboardLayout,
+  FavoriteLink, SearchProvider, TenderEmailConfig, TenderNotificationPref,
+  TenderRssFeedSource, TenderSavedSearch, TenderTriage, WidgetInstance)
+  pruefen `current_user_id() IS NULL OR "userId" = current_user_id()` —
+  ein Aufruf OHNE gesetzten Benutzer (Admin, Hintergrunddienst) sieht
+  weiterhin den ganzen Mandanten, das macht die Aenderung fuer heutige
+  Aufrufer wirkungslos.
 
 ## 3. Der Sperrgrund — warum die Umstellung noch nicht erfolgt ist