docs(quick-260914-eym): Etappe 3c abgeschlossen — Kritikschrift, Klassifikation, Auftrag, Datenbankrolle, WINDOWS #21/#30 geschlossen, Single-Flight-Riegel als Eintrag

- Kritikschrift: neuer Abschnitt "## Systemkontext (Etappe 3c, 260914-eym)"
  mit (y1) woertlicher Werkzeugausgabe und pg_policies der lebenden DB,
  (y2) Signaltabelle beider Fehlerrichtungen samt Rueckbau-Belegen (a)-(d),
  (y3) Leere-als-Abwesenheit je Pfad (kein Pfad loescht), (y4) bewusst
  nicht geloest, (y5) bewusst nicht angefasst; Nachtraege in (d4), (s4),
  (b4) und im Abschluss
- Klassifikation: Uebersichtstabelle mit dritter Spalte System, Werte
  nachgerechnet (61/179/5), Stand-Absatz 260914-eym (72 Paare, Klassen
  unveraendert, sieben Staende geaendert), sechs Regelschluesse im
  Hintergrunddienst-Abschnitt, admin-seed-Zeile mit 3c-Befund, 3c-Punkt
  unter "NICHT entscheidet" erledigt
- Auftrag: 3c als Erledigt vermerkt (3d64567/6e2a641), zwei neue Fallen
  unter "Werkzeuge und Fallen"
- Datenbankrolle: dritte Sitzungsvariable, Nachtrag zum Systemkontext und
  zur weiterhin gueltigen Vorher-Pruefung ohne-kontext-leer
- Ledger (ueber gsd-tools windows): #21 fixed, #30 fixed, #37 neu
  (prozessweiter Single-Flight-Riegel processInbox) — open 15 / waived 1 /
  fixed 21 / total 37, aus den Zeilen gezaehlt

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY

docs/mandantentrennung-datenbankrolle.md

@@ -85,6 +85,25 @@ noetig sind:
   ein Aufruf OHNE gesetzten Benutzer (Admin, Hintergrunddienst) sieht
   weiterhin den ganzen Mandanten, das macht die Aenderung fuer heutige
   Aufrufer wirkungslos.
+- **Eine dritte Sitzungsvariable fuer den Systemkontext.** Migration
+  `20260914120000_rls_system_context_read` (Etappe 3c, 260914-eym) bringt
+  `app.system_context` und die Funktion `is_system_context()` —
+  `COALESCE(current_setting('app.system_context', true) = 'true', false)`,
+  damit die Regel ohne gesetzte Variable FALSE sieht, nicht NULL — sowie je
+  eine zusaetzliche PERMISSIVE Regel `system_read_policy ... FOR SELECT
+  USING (is_system_context())` auf genau den fuenf Tabellen, die die
+  Hintergrunddienste ueber alle Mandanten LESEN (DkvModuleConfig, LdapConfig,
+  LdapFieldMapping, TenderMatch, TenderSavedSearch). Permissive Regeln werden
+  ODER-verknuepft: fuer SELECT gilt (Mandantenregel ODER Systemregel), fuer
+  INSERT/UPDATE/DELETE weiter NUR die Mandantenregel — unter Systemkontext
+  ist `current_tenant_id()` der Leerstring, jedes Schreiben faellt durch
+  (gemessen: 42501 / count 0 / P2025). Der Helfer `forSystem()` setzt
+  `app.system_context = 'true'` und die beiden anderen Variablen
+  AUSDRUECKLICH leer; `forTenant()` und `withTenantTransaction()` setzen
+  umgekehrt `app.system_context = ''` — kein Kontext erbt vom anderen
+  (`local=true` als erstes Netz, der Reset als zweites, beides im Werkzeug
+  gemessen und durch Rueckbau belegt). Kein `GRANT EXECUTE` noetig, wie bei
+  den beiden anderen Funktionen.
 
 ## 3. Der Sperrgrund — warum die Umstellung noch nicht erfolgt ist
 
@@ -135,6 +154,21 @@ werden darf. Das ist **eigene Arbeit und nicht Teil dieser Aenderung**
 Abschnitt 5 belegt ausschliesslich, dass die Datenbankseite stimmt — er sagt
 nichts ueber diese Zugriffe aus.
 
+**Nachtrag (260914-eym, Etappe 3c):** der Systemkontext ist gebaut — siehe
+den Punkt "Eine dritte Sitzungsvariable" in Abschnitt 2 und
+`docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt
+"## Systemkontext (Etappe 3c, 260914-eym)". Vier Hintergrunddienst-Dateien
+lesen ueber `forSystem()`, der Mail-Startpfad ist entfernt, die Erstanlage
+des Administrators liest nur `Tenant` (keine Regel). Die Vorher-Pruefung
+`ohne-kontext-leer` in `rls-preflight.mjs` (Abschnitt 5) bleibt GUELTIG und
+wird durch die neue Regel NICHT gelockert: ohne gesetzte Variable ist
+`is_system_context()` false — Werkzeugbeleg
+`is-system-context-ungesetzt-false` (`rls-scratch-check.mjs`, Rohwert
+`null` -> `false`). Etappe 4 ergaenzt die Vorher-Pruefung um
+`mit-systemkontext-sichtbar` (mit `app.system_context = 'true'` sind die
+fuenf Tabellen lesbar); `rls-preflight.mjs` ist in 3c bewusst nicht
+angefasst.
+
 **Zusaetzlicher Sperrgrund, ebenfalls am 2026-09-09 gemessen (WINDOWS #20):**
 `forTenant()` selbst war bis Aufgabe 1 dieser Etappe defekt — `set_config()`
 lief auf einer anderen Datenbankverbindung als die eigentliche Abfrage, sodass