docs(quick-260911-cwh): Bereich calendar Etappe 2 abgeschlossen — restliche Dokumentstellen nachgezogen (Aufgabe 3)

- docs/mandantentrennung-zugriffsklassifikation.md: Uebersichtszeile
  calendar auf 0/12 gezogen (war 12/0, kein ungebundener Rest — erster
  Bereich in Folge ohne begruendeten Rest), Summenzeile auf 83/159
  fortgeschrieben, Klassen-Verteilung unveraendert mit ausdruecklichem
  Stand-260911-cwh-Vermerk, Hintergrunddienst-Abschnitt um den
  Sonderfall refreshCacheInBackground (abgekoppelte Fortsetzung, kein
  sechster Fall) ergaenzt, Abschnitt "Was diese Etappe NICHT entscheidet"
  um calendar ergaenzt
- .planning/WINDOWS.md: neuer offener Eintrag (#26) zur lautlosen
  Auspraegung der umgekehrten Fehlerrichtung im Bereich calendar, ueber
  gsd-tools windows append angelegt
- Beide Falsifizierungsnachweise durchgefuehrt (falscher Stand macht
  rls-access-inventory.spec.ts rot; falsche Uebersichtszahl macht das
  herleitende Gate rot), zurueckgenommen
- Etappe 2, neunter Bereich (calendar) abgeschlossen: alle zwoelf
  Zugriffe gebunden, Baseline gehalten (883 Tests, 57 Dateien, 101
  Werkzeugpruefungen, Typpruefung sauber)

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

docs/mandantentrennung-zugriffsklassifikation.md

@@ -124,11 +124,11 @@ autoritative Quelle.
 | module-registry | 7 | 10 | **war 17/0** — Aufgabe 2/3 (260910-exd) haben `module-access.service.ts` (`getAccessibleModuleIds`: Kurzschlusszweig, Direktweg, Gruppenweg, Schnittmenge; `getCatalogFlags`: eigener Aktivierungs-Lesezugriff) und `module-registry.service.ts` (`findActiveForTenant`, `activateForTenant`, `deactivateForTenant`, `isModuleActive`) auf `forTenant()` umgestellt. Die 7 verbleibenden ungebundenen Rohtreffer sind bewusst: der eine Katalogzugriff in `module-access.service.ts` (`findAccessibleModules`) und die sechs Katalogzugriffe in `module-registry.service.ts` (`findAll`, `findBySlug`, die beiden Katalog-Existenzpruefungen in `activateForTenant`/`deactivateForTenant`, die Katalogsuche in `isModuleActive`, `seedModule`) — der Modulkatalog (`Module`) traegt heute keinen Zeilenschutz, eine Bindung waere heute wirkungslos, nicht katastrophal; katastrophal wuerde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt (Befund E) |
 | dashboard | 1 | 12 | **war 13/0** — Aufgabe 2/3 (260910-krx) haben `dashboard.service.ts` vollständig umgestellt: `getLayout`/`saveLayout` (gemeinsam gebunden), `getWidgets`/`addWidget`/`updateWidgetConfig`/`removeWidget` sowie `getSearchProviders`/`addSearchProvider`/`removeSearchProvider` laufen über `forTenant()`, je Methode ein Klient. Der eine verbleibende ungebundene Rohtreffer ist bewusst: der Modulkatalog (`Module`) trägt heute keinen Zeilenschutz, eine Bindung wäre heute wirkungslos, nicht katastrophal — katastrophal würde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt (Befund E aus `module-registry`, hier übernommen) |
 | auth | 8 | 5 | unverändert gegenüber dem in Etappe 1 (260909-eor) gemessenen Stand |
-| calendar | 12 | 0 | unverändert |
+| calendar | 0 | 12 | **war 12/0** — Aufgabe 2 (260911-cwh) hat `calendar.service.ts` vollständig auf `forTenant()` umgestellt: `getSources`, `addSource`, beide Abfragen von `updateSource`/`deleteSource`, alle drei Abfragen von `testConnection`, Laden plus beide Synchronstatus-Rückschreibungen von `fetchAndCacheEvents` — je Methode ein Klient. Anders als bei den sieben Bereichen davor bleibt KEIN ungebundener Rest übrig: `CalendarSource` trägt eine Pflicht-Mandantenkennung, und kein Pfad dieses Bereichs liest über Mandanten hinweg |
 | tenant | 8 | 0 | unverändert |
 | favorites | 7 | 0 | unverändert |
 | settings | 4 | 0 | unverändert |
-| **Summe** | **95** | **147** | Ungebunden: war 118 nach 260910-das, dann 108 nach 260910-exd (module-registry 17→7), dann 107 nach 260910-jab (`tenders` 36→35, `listForUser` gebunden), jetzt 95 nach 260910-krx (`dashboard` 13→1). Gebunden: war 124, dann 134 nach 260910-exd (zusätzlich 10 in `module-registry`), dann 135 nach 260910-jab (zusätzlich 1 in `tenders`), jetzt 147 nach 260910-krx (zusätzlich 12 in `dashboard`). Diese Übersicht ist eine Buchführungshilfe; **autoritativ ist die Fundstellentabelle unten**, die `rls-access-inventory.spec.ts` bei jedem Lauf gegen den Quelltext prüft |
+| **Summe** | **83** | **159** | Ungebunden: war 118 nach 260910-das, dann 108 nach 260910-exd (module-registry 17→7), dann 107 nach 260910-jab (`tenders` 36→35, `listForUser` gebunden), dann 95 nach 260910-krx (`dashboard` 13→1), jetzt 83 nach 260911-cwh (`calendar` 12→0). Gebunden: war 124, dann 134 nach 260910-exd (zusätzlich 10 in `module-registry`), dann 135 nach 260910-jab (zusätzlich 1 in `tenders`), dann 147 nach 260910-krx (zusätzlich 12 in `dashboard`), jetzt 159 nach 260911-cwh (zusätzlich 12 in `calendar`). Diese Übersicht ist eine Buchführungshilfe; **autoritativ ist die Fundstellentabelle unten**, die `rls-access-inventory.spec.ts` bei jedem Lauf gegen den Quelltext prüft |
 
 ## Klassen-Verteilung (nach (Datei, Modell)-Fundstellen, 63 Paare)
 
@@ -178,6 +178,16 @@ ohne diesen Vermerk waere von einer vergessenen Nachziehung nicht zu
 unterscheiden — deshalb steht die Abwesenheit einer Aenderung hier
 ausdruecklich, statt stillschweigend uebersprungen zu werden.
 
+**Stand 260911-cwh (Aufgabe 3): unveraendert, ausdruecklich festgehalten
+statt uebersprungen.** Weiterhin 63 Paare, keine Klasse verschoben sich. Das
+eine Paar des Bereichs `calendar` (`calendar.service.ts`/`calendarSource`)
+war bereits vor diesem Durchlauf korrekt klassifiziert (`muss-mandantengebunden`)
+— Aufgabe 2 (260911-cwh) aendert nur seine `Stand`-Spalte (`ungebunden` auf
+`gebunden`), nicht seine Klasse. Eine unveraenderte Tabelle ohne diesen
+Vermerk waere von einer vergessenen Nachziehung nicht zu unterscheiden —
+deshalb steht die Abwesenheit einer Aenderung hier ausdruecklich, statt
+stillschweigend uebersprungen zu werden.
+
 | Klasse | Anzahl Paare |
 |---|---|
 | muss-mandantengebunden | 31 |
@@ -304,6 +314,25 @@ bekannten Nutzers heraus aufgerufen — die Bauform dieses Abschnitts
 (übergreifend LESEN über alle Mandanten, dann je Mandant BINDEN) kommt in
 diesem Bereich an keiner Stelle vor.
 
+**Stand 260911-cwh — auch der Bereich `calendar` fügt diesem Abschnitt
+keinen sechsten Fall hinzu, gemessen statt angenommen (260911-cwh, Aufgabe 1,
+Befund B).** `grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout" apps/api/src/calendar --include=*.ts`
+liefert außerhalb von Testdateien genau einen Treffer,
+`providers/ics.provider.ts:100` — ein `setTimeout` für den Abbruch eines
+HTTP-Abrufs nach acht Sekunden, kein Planer. Der einzige Dienst dieses
+Bereichs, `calendar.service.ts`, enthält keinen Hintergrunddienst, keinen
+Planer und keinen Start-Hook — die Bauform dieses Abschnitts (übergreifend
+LESEN über alle Mandanten, dann je Mandant BINDEN) kommt an keiner Stelle
+vor. Es gibt aber einen benannten Sonderfall, anderer Bauart als die fünf
+Fälle oben: `refreshCacheInBackground` (private Methode) ist eine
+ABGEKOPPELTE FORTSETZUNG einer Anfrage — `aggregateEvents` stößt sie an,
+wartet nicht auf sie, und sie ruft `fetchAndCacheEvents` mit den Parametern
+der ursprünglichen Anfrage auf. Sie iteriert NICHT über mehrere Mandanten
+und hat deshalb keine übergreifende Hälfte zu binden — sie trägt die
+Mandantenkennung der Anfrage, die sie ausgelöst hat, und kann strukturell
+keine andere haben. Kein Kandidat für diese Liste; dieser Absatz hält die
+Abwesenheit fest, damit sie nicht wie ein Übersehen aussieht.
+
 ## Bestandsaufnahme
 
 Maschinell ermittelt, `rls-access-inventory.spec.ts` hält Vollständigkeit
@@ -392,8 +421,11 @@ verwendet), Klasse, Stand (`gebunden`/`ungebunden`/`gemischt`, seit
   werden nicht zwischen Methoden weitergereicht. Der Bereich `dashboard`
   (260910-krx) hat sich für denselben dienst-internen Weg entschieden — jede
   der neun umgestellten Methoden in `dashboard.service.ts` erzeugt ihren
-  eigenen `forTenant()`-Aufruf, wie alle sieben Bereiche vor ihm. Die Frage
-  bleibt für alle übrigen Bereiche der Etappe 2 offen.
+  eigenen `forTenant()`-Aufruf, wie alle sieben Bereiche vor ihm. Der Bereich
+  `calendar` (260911-cwh) hat sich für denselben dienst-internen Weg
+  entschieden — jede der sechs umgestellten Methoden in `calendar.service.ts`
+  erzeugt ihren eigenen `forTenant()`-Aufruf, wie alle acht Bereiche vor ihm.
+  Die Frage bleibt für alle übrigen Bereiche der Etappe 2 offen.
 - ~~Wie die WINDOWS-#19-Policy für `SearchProvider`/`TenderRssFeedSource`
   am Ende genau lautet — nur, dass sie vor dem Scharfschalten gelöst sein
   muss.~~ Aufgelöst (260910-jab): `TenderRssFeedSource` bekommt vier nach