diff --git a/.planning/quick/260911-gwh-mandantentrennung-etappe-2-bereiche-favo/260911-gwh-PLAN.md b/.planning/quick/260911-gwh-mandantentrennung-etappe-2-bereiche-favo/260911-gwh-PLAN.md
new file mode 100644
index 0000000..44bd002
--- /dev/null
+++ b/.planning/quick/260911-gwh-mandantentrennung-etappe-2-bereiche-favo/260911-gwh-PLAN.md
@@ -0,0 +1,1226 @@
+---
+phase: quick-260911-gwh
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+autonomous: true
+requirements: [WINDOWS-18, ETAPPE-2-FAVORITES, ETAPPE-2-SETTINGS]
+
+files_modified:
+  - apps/api/scripts/rls-scratch-check.mjs
+  - docs/mandantentrennung-etappe2-fehlerrichtung.md
+  - apps/api/src/favorites/favorites.service.ts
+  - apps/api/src/favorites/favorites.service.spec.ts
+  - apps/api/src/favorites/favorites.controller.ts
+  - apps/api/src/settings/settings.service.ts
+  - apps/api/src/settings/settings.service.spec.ts
+  - apps/api/src/mail/mail.module.ts
+  - docs/mandantentrennung-zugriffsklassifikation.md
+  - docs/anleitung-entwicklung.md
+  - .planning/WINDOWS.md
+
+estimate:
+  tokens: 210000
+  raw_tokens: 210000
+  tasks: 3
+  confidence: low
+
+must_haves:
+  truths:
+    - "Beide Bereiche sind GEMESSEN, bevor eine Zeile Quelltext angefasst wird: `runFavoritesAreaChecks` und `runSettingsAreaChecks` messen an den Regeln fuer `FavoriteLink` und `SmtpConfig` WORTGLEICH aus `20260909140000_rls_remaining_tenant_tables` (Regelstand eindeutig, die Widen-Migration hat keine eigene Regel fuer beide), je Bereich mindestens einen Pfad ueber den GENERIERTEN Client an einer Wegwerf-Tabelle, deren Spaltenmenge zur Laufzeit gegen die SKALAREN Felder des Modells geprueft wird (`createdAt`/`updatedAt` eingeschlossen)."
+    - "Der Startpfad des Mailmoduls ist als SECHSTER Fall der Hintergrunddienst-Falle erkannt, gemessen und markiert, NICHT gebunden und NICHT zu einem Mehrmandanten-Versand umgebaut: die Methode traegt einen Namen, der sie nicht mit einem Anfrageweg verwechseln laesst, ihr Kopf nennt BEIDE Zustaende (heute: beliebiger Mandant liefert den SMTP-Server fuer ALLE Systemmails; nach dem Scharfschalten: `null`, und die Rueckfallkette des Moduls verdeckt das Verstummen mit einem falschen Transport statt es zu melden), die Unsymmetrie zu `ldap`/`dkv` (Rueckfallkette statt blosser Leere) und die Entscheidung EIGENER Ledger-Eintrag statt Anschluss an #21 — mit Grund."
+    - "Befund K (`tenders` (t4)) und die Uebergabe in `dkv` (d4) sind ERFUELLT und stehen als solche an drei Stellen: `getDecryptedSmtpConfig(tenantId)` — der EINZIGE Versandpfad von `tender-mail.service.ts` und `dkv-mail.service.ts` — laeuft ueber `tenantPrisma`; ein Nachtrag unter Befund K in (t4), ein Nachtrag im Uebergaben-Absatz von (d4), und die Ordnungsnotiz im Klassifikationsdokument sagen es ausdruecklich, damit die Etappe-4-Vorabpruefung keine veraltete Bedingung mitschleppt."
+    - "Alle sieben Zugriffe in `favorites.service.ts` und die drei Anfragewege in `settings.service.ts` laufen je Methode ueber GENAU EINEN Klienten `tenantPrisma`; die Besitzpruefungen (findUnique, dann Vergleich der Benutzerkennung, dann Schreibzugriff auf DEMSELBEN Klienten) bleiben bestehen; `create` prueft zusaetzlich, dass das Ziel-Widget dem Aufrufer gehoert (der Fremdschluessel umgeht den Zeilenschutz — gemessen, Pruefung 7)."
+    - "Die umgekehrte Fehlerrichtung ist je Bereich in ihrer TATSAECHLICHEN Auspraegung benannt und gemessen: eine leere Favoritenleiste liest sich als `Noch keine Favoriten.` (favorites-widget.tsx); eine unsichtbare SMTP-Zeile liest sich als leeres Formular (200 mit leerem Rumpf, `res.json()` wirft, `.catch(() => {})` verschluckt — dieselbe Kette wie #28), waehrend die Zugangsdaten physisch noch da sind und ein erneutes Speichern unter der ungebundenen Form am Eindeutigkeitsindex scheitert (gemessen, Konstruktorname und `code` woertlich)."
+    - "Die Testlage traegt: `favorites.service.spec.ts` und `settings.service.spec.ts` existieren NEU mit dem Zwei-Klienten-Nachbau (ungebunden OHNE Anfrage-Modelle, gebunden OHNE `findFirst`), der Icon-Dienst und `nodemailer` sind Attrappen (kein echter Transport — lokal gibt es keinen `mailhog`), und vier Falsifizierungsnachweise sind durchgefuehrt, zurueckgenommen und woertlich notiert."
+    - "Etappe 2 ist mit diesem Lauf VOLLSTAENDIG: die Uebersichtstabelle, Summenzeile, Bestandsaufnahme, Klassen-Verteilung und der Hintergrunddienst-Abschnitt des Klassifikationsdokuments stehen auf ihrem Endstand fuer Etappe 2 — DERIVIERT gegatet, nicht abgeschrieben —, jede Fundstelle in `apps/api/src` ist gebunden oder mit geschriebenem Grund an der Stelle ungebunden, und die Kritikschrift traegt einen Abschluss-Abschnitt mit den Zahlen aus den eigenen Messanweisungen sowie dem, was fuer Etappe 3 bleibt."
+    - "Baseline gehalten am Ende JEDER Aufgabe: mindestens 951 Tests gruen in mindestens 60 Dateien (nach Aufgabe 2 mehr, in mindestens 62 Dateien), Typpruefung sauber, Werkzeug alle Pruefungen bestanden (mindestens 135). Schalter AUS, Schema und Migrationen unveraendert, keine Compose- oder Umgebungsdatei, nichts in Active Directory; Erlaubnisliste gegen `46f0e78`."
+  artifacts:
+    - "apps/api/scripts/rls-scratch-check.mjs — zwei neue Abschnitte `runFavoritesAreaChecks` (Wegwerf-Tabelle `FavoriteLink` mit Fremdschluessel auf die bestehende Wegwerf-Tabelle `WidgetInstance`) und `runSettingsAreaChecks` (Wegwerf-Tabelle `SmtpConfig` mit Eindeutigkeitsindex auf `tenantId`), je mindestens sieben namentlich benannte Pruefungen, in `main()` NACH `runAuthAreaChecks` und VOR `runTransactionShapeMeasurement`"
+    - "docs/mandantentrennung-etappe2-fehlerrichtung.md — Abschnitte `## Bereich favorites` ((f1)-(f5)) und `## Bereich settings` ((s1)-(s5)) sowie `## Etappe 2 — Abschluss`, alle VOR `## Verweis`; Nachtraege unter Befund K in (t4) und im Uebergaben-Absatz von (d4)"
+    - "apps/api/src/favorites/favorites.service.ts — `list(tenantId, userId, widgetId)`, `create(tenantId, userId, dto)`, `update(tenantId, id, userId, dto)`, `remove(tenantId, id, userId)`, `getIconBytes(tenantId, id, userId)` je mit EINEM Klienten `tenantPrisma`; Widget-Besitzriegel in `create`"
+    - "apps/api/src/favorites/favorites.service.spec.ts — NEU: Zwei-Klienten-Nachbau fuer `favoriteLink` und `widgetInstance`, Icon-Dienst als Attrappe, Wachhund, Grenzfaelle"
+    - "apps/api/src/favorites/favorites.controller.ts — reicht `tenantId` aus `extractContext` an alle fuenf Dienstmethoden durch; Kopfkommentar nennt die Mandantenquelle und den dashboard-Praezedenzfall"
+    - "apps/api/src/settings/settings.service.ts — `getSmtpConfig`, `saveSmtpConfig`, `getDecryptedSmtpConfig` je mit EINEM Klienten `tenantPrisma`; der Startpfad umbenannt in `loadAnySmtpConfigForStartupTransport()`, weiterhin auf dem ungebundenen Klienten, mit Kopfkommentar beider Zustaende, Unsymmetrie, Reparaturweg und Ledger-Nummer"
+    - "apps/api/src/settings/settings.service.spec.ts — NEU: Zwei-Klienten-Nachbau fuer `smtpConfig` (ungebunden NUR `findFirst`, gebunden NUR `findUnique`/`upsert`), `nodemailer` und `CryptoService` als Attrappen, Wachhund je Anfrageweg, Null-Klienten-Nachweis fuer den Startpfad"
+    - "apps/api/src/mail/mail.module.ts — ruft den umbenannten Startpfad auf; Modulkommentar nennt beide Zustaende und die Rueckfallkette als Verdeckung"
+    - "docs/mandantentrennung-zugriffsklassifikation.md — Uebersichtszeilen `favorites`/`settings` mit neu gemessenen Zahlen, Summenzeile, Bestandsaufnahme-Zeilen (`favoriteLink` auf `gebunden`, `smtpConfig` auf `gemischt`, neue Zeile `favorites.service.ts`/`widgetInstance`), Klassen-Verteilung mit Stand-Vermerk und neuer Summe, Hintergrunddienst-Abschnitt mit sechstem Fall und angepasster Ueberschrift, `Was diese Etappe NICHT entscheidet` mit dem Mehrmandanten-Versand-Punkt und der erfuellten Befund-K-Bedingung"
+    - "docs/anleitung-entwicklung.md — der Absatz, der `FavoriteLink` als Tabelle OHNE Regel und `DkvService.loadConfig()` als ungebunden nennt, auf den gemessenen Stand gebracht (drei Regel-Migrationen, 23 Tabellen)"
+    - ".planning/WINDOWS.md — drei neue OFFENE Eintraege ueber `gsd-tools windows append`: Startpfad des Mailmoduls (eigener Eintrag), verschluckte Leere `favorites` (favorites-widget.tsx), verschluckte Leere `settings` (smtp-settings-form.tsx)"
+  key_links:
+    - "`tender-mail.service.ts:158` und `dkv-mail.service.ts:47` rufen `settingsService.getDecryptedSmtpConfig(tenantId)` — der Mandant kommt aus der jeweiligen gebundenen Schleife (260909-laa, 260909-mir). Bindet diese Methode, ist Befund K geschlossen; bleibt sie ungebunden, geht nach dem Scharfschalten KEINE Ausschreibungs- und KEINE DKV-Mail mehr raus (tender: `warn` + `null`, dkv: `throw`)."
+    - "`mail.module.ts:30` ruft den Startpfad in einer asynchronen `useFactory` VOR jedem Anfragekontext; liefert er `null`, greift Prioritaet 2-4 (Umgebungsvariablen, zuletzt `localhost:1025`) — `MailService.sendPasswordResetEmail` faengt jeden Transportfehler (T-02-12) und antwortet 200: das Verstummen ist doppelt verdeckt."
+    - "`FavoriteLink.widgetId` -> `WidgetInstance.id` (Fremdschluessel, ON DELETE CASCADE, 20260708090000): Fremdschluesselpruefungen laufen in PostgreSQL an der Zeilenschutz-Regel VORBEI — der Bezug auf ein fremdes Widget ist auf Datenbankebene nicht gesperrt (Pruefung 7 misst das); der Besitzriegel in `create` ist deshalb anwendungsseitig."
+    - "`favorites.controller.ts` `extractContext` liest `req.tenantId ?? req.user?.tenantId` — dieselbe Quelle wie `dashboard.controller.ts`, unter dessen Bindung `WidgetInstance` liegt. Eine andere Quelle wuerde Widget und Link unter einem `x-tenant-id`-Wechsel an verschiedene Mandanten binden; `favorites-api.ts` sendet die Kopfzeile nicht (gemessen)."
+    - "`settings.controller.ts` liest `req.tenantId` — fuer eine ADMIN-Konfigurationsseite die RICHTIGE Quelle (D-10: SUPER_ADMIN konfiguriert ueber `x-tenant-id` einen anderen Mandanten); die Selbstbedienungs-Begruendung aus `auth` (Claim) gilt hier NICHT, der Controller bleibt unveraendert."
+    - "`SmtpConfig_tenantId_key` (20260629130000) ist der Eindeutigkeitsindex, an dem ein ungebundenes `upsert` auf eine unsichtbare Zeile scheitert — die `dashboard`-Lehre (260910-krx, `PrismaClientUnknownRequestError` statt P2002) zur Ausfuehrungszeit erneut messen, nicht abschreiben."
+---
+
+<!-- planner-discipline-allow: this.prisma.favoriteLink -->
+<!-- planner-discipline-allow: this\.prisma\.favoriteLink -->
+<!-- planner-discipline-allow: this.prisma.smtpConfig -->
+<!-- planner-discipline-allow: this\.prisma\.smtpConfig -->
+<!-- planner-discipline-allow: getStartupSmtpConfig -->
+<!-- planner-discipline-allow: forTenant -->
+<!-- planner-discipline-allow: tenantId -->
+<!-- planner-discipline-allow: tenantPrisma.findFirst -->
+<!-- planner-discipline-allow: findFirst -->
+<!-- planner-discipline-allow: PrismaService -->
+<!-- planner-discipline-allow: fünf Fälle -->
+
+<objective>
+Etappe 2 der Mandantentrennung, LETZTER Lauf: die Bereiche `favorites` (sieben
+ungebundene Zugriffe auf `favoriteLink` in fuenf Methoden) und `settings`
+(vier ungebundene Zugriffe auf `smtpConfig` in vier Methoden) — zwei kleine
+Bereiche gleicher Bauform, als EIN Durchlauf, weil keiner allein drei
+Aufgaben traegt.
+
+Zweck, dreifach. Erstens: `settings` haelt die SMTP-Zugangsdaten je Mandant,
+und `getDecryptedSmtpConfig(tenantId)` ist der einzige Versandpfad fuer
+Ausschreibungs-Meldungen und DKV-Ausfuhren. Der `tenders`-Lauf hat als Befund
+K festgehalten: bleibt diese Methode ungebunden, geht nach dem Scharfschalten
+fuer NIEMANDEN eine Mail raus. Dieser Lauf schliesst diese Bedingung und sagt
+das an jeder Stelle, an der sie steht. Zweitens: `getStartupSmtpConfig()` ist
+der SECHSTE Fall der Hintergrunddienst-Falle — ein Startpfad ohne
+Mandantenkontext, der heute eine BELIEBIGE Zeile zieht (der SMTP-Server eines
+beliebigen Mandanten bedient alle Systemmails) und nach dem Scharfschalten
+`null` liefert; anders als bei `dkv` (WINDOWS #21) verdeckt hier eine
+Rueckfallkette das Verstummen mit einem falschen Transport. Der Pfad wird
+gemessen, benannt, markiert und als eigener Ledger-Eintrag gefuehrt — NICHT
+gebunden, NICHT zu einem Mehrmandanten-Versand umgebaut (das ist eine
+Funktion, dieselbe Klasse wie #21). Drittens: `favorites` ist Nutzerdaten
+mit der findUnique-dann-loeschen-Bauform, die dieses Vorhaben zweimal falsch
+und zweimal richtig vorgefunden hat — sie wird gelesen und gemessen, und der
+Fremdschluessel auf `WidgetInstance` (der den Zeilenschutz umgeht) bekommt
+einen anwendungsseitigen Besitzriegel.
+
+Nach diesem Lauf ist Etappe 2 vollstaendig: jede klassifizierte Fundstelle in
+`apps/api/src` ist gebunden oder mit geschriebenem Grund an der Stelle
+ungebunden. Die fuenf handgepflegten Dokumentstellen erreichen ihren Endstand,
+die Kritikschrift bekommt einen Abschluss-Abschnitt aus ihren eigenen Zahlen.
+
+**Der Schalter bleibt AUS.** `DATABASE_URL` zeigt weiterhin auf die Rolle
+`tessera` mit `BYPASSRLS`. Schema und Migrationen werden NICHT angefasst.
+Nichts wird in Active Directory geaendert. Kein echter SMTP-Transport wird
+aufgebaut (lokal gibt es keinen `mailhog`; `ENOTFOUND mailhog` waere
+Umgebung, nicht Befund).
+</objective>
+
+<execution_context>
+@~/.claude/gsd-core/workflows/execute-plan.md
+@~/.claude/gsd-core/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/STATE.md
+@docs/mandantentrennung-zugriffsklassifikation.md
+@docs/mandantentrennung-etappe2-fehlerrichtung.md
+@docs/anleitung-entwicklung.md
+@apps/api/prisma/migrations/20260909140000_rls_remaining_tenant_tables/migration.sql
+@apps/api/prisma/migrations/20260910120000_rls_widen_membership_grant_and_platform_read/migration.sql
+@apps/api/prisma/migrations/20260708090000_add_favorite_link/migration.sql
+@apps/api/prisma/migrations/20260629130000_add_missing_tables/migration.sql
+@apps/api/prisma/schema.prisma
+@apps/api/src/prisma/prisma-tenant.extension.ts
+@apps/api/src/prisma/rls-access-inventory.spec.ts
+@apps/api/scripts/rls-scratch-check.mjs
+@apps/api/src/favorites/favorites.service.ts
+@apps/api/src/favorites/favorites.controller.ts
+@apps/api/src/favorites/favorites.module.ts
+@apps/api/src/favorites/icon-discovery.service.ts
+@apps/api/src/favorites/icon-discovery.service.spec.ts
+@apps/api/src/favorites/dto/create-favorite.dto.ts
+@apps/api/src/favorites/dto/update-favorite.dto.ts
+@apps/api/src/settings/settings.service.ts
+@apps/api/src/settings/settings.controller.ts
+@apps/api/src/settings/settings.module.ts
+@apps/api/src/settings/dto/smtp-config.dto.ts
+@apps/api/src/mail/mail.module.ts
+@apps/api/src/mail/mail.service.ts
+@apps/api/src/tenders/tender-mail.service.ts
+@apps/api/src/tenders/tender-mail.service.spec.ts
+@apps/api/src/dkv/dkv-mail.service.ts
+@apps/api/src/dkv/dkv.service.ts
+@apps/api/src/dkv/dkv-scheduler.service.ts
+@apps/api/src/dkv/dkv.service.spec.ts
+@apps/api/src/calendar/calendar.service.spec.ts
+@apps/api/src/dashboard/dashboard.service.spec.ts
+@apps/api/src/dashboard/dashboard.controller.ts
+@apps/api/src/tenant/tenant.guard.ts
+@apps/web/src/lib/favorites-api.ts
+@apps/web/src/components/dashboard/widgets/favorites-widget.tsx
+@apps/web/src/lib/settings-api.ts
+@apps/web/src/components/settings/smtp-settings-form.tsx
+@apps/web/src/messages/de.json
+@.planning/WINDOWS.md
+@.planning/quick/260911-fh9-mandantentrennung-etappe-2-bereich-auth-/260911-fh9-PLAN.md
+@.planning/quick/260911-fh9-mandantentrennung-etappe-2-bereich-auth-/260911-fh9-SUMMARY.md
+</context>
+
+<planning_time_findings>
+
+Alle Zahlen unten sind zur Planungszeit am 2026-09-11 gegen HEAD `46f0e78`
+GEMESSEN, mit der jeweils angegebenen Anweisung. Sie leiten die Untersuchung,
+sie sind KEINE Bearbeitungsvollmacht — jede Datei wird vor jeder Aenderung
+erneut gelesen, jede Zahl zur Ausfuehrungszeit erneut gemessen, und weicht
+eine Messung ab, gilt die Messung und nicht dieser Plan. Baseline laut
+`260911-fh9-SUMMARY.md`: 951 Tests gruen in 60 Dateien, Typpruefung sauber,
+Werkzeug 120/120 — zur Ausfuehrungszeit VOR der ersten Aenderung selbst
+nachmessen.
+
+**Befund A — die Zahlen halten: 7/0 und 4/0, beide Bereiche ohne einen
+einzigen gebundenen Zugriff.**
+`grep -rno "this\.prisma\.[a-zA-Z]*" apps/api/src/favorites apps/api/src/settings | grep -v spec`:
+sieben Treffer in `favorites.service.ts` (Zeilen 34 `list`/findMany, 55
+`create`/create, 74 `update`/findUnique, 103 `update`/update, 114
+`remove`/findUnique, 120 `remove`/delete, 138 `getIconBytes`/findUnique) und
+vier in `settings.service.ts` (39 `getSmtpConfig`/findUnique, 74
+`saveSmtpConfig`/upsert, 97 `getDecryptedSmtpConfig`/findUnique, 193
+`getStartupSmtpConfig`/findFirst). Gebunden: null. Nach diesem Plan:
+`favorites` 0 ungebunden / 7 gebunden (8, wenn der Besitzriegel aus Befund F
+einen `widgetInstance`-Lesezugriff hinzufuegt); `settings` 1 ungebunden (der
+Startpfad) / 3 gebunden. Summenzeile 78 -> 67 und 167 -> 177 (bzw. 178).
+Bestandsaufnahme: `favorites.service.ts`/`favoriteLink` von `ungebunden` auf
+`gebunden`; `settings.service.ts`/`smtpConfig` von `ungebunden` auf
+`gemischt` (dieselbe Form wie `dkv.service.ts`/`dkvModuleConfig`: die
+Mischung stammt ausschliesslich vom benannten Startpfad); NEUE Zeile
+`favorites.service.ts`/`widgetInstance` (`muss-mandantengebunden`,
+`gebunden`), wenn Befund F den Riegel bestaetigt -> 65 Paare, 33/17/13/2.
+Alle Zahlen zur Ausfuehrungszeit aus den Messanweisungen des Dokuments
+ableiten, nicht von hier abschreiben.
+
+**Befund B — die Regeln sind eindeutig und wortgleich extrahierbar.**
+`20260909140000_rls_remaining_tenant_tables` traegt fuer `FavoriteLink`
+(Zeile 88-92) und `SmtpConfig` (102-106) je ENABLE + FORCE + `CREATE POLICY
+tenant_isolation_policy ... USING ("tenantId" = current_tenant_id())`;
+`grep -c "FavoriteLink\|SmtpConfig" 20260910120000_.../migration.sql`: 0 —
+die Widen-Migration hat keine eigene Regel fuer beide (Regelstand eindeutig,
+Form von `calendarsource-regelstand-eindeutig`). Spalten: `FavoriteLink`
+(20260708090000) hat 10 skalare Spalten (`id`, `userId`, `tenantId`,
+`widgetId`, `title`, `url`, `iconUrl`, `position`, `createdAt`, `updatedAt`)
+und den Fremdschluessel `FavoriteLink_widgetId_fkey` auf `"WidgetInstance"("id")
+ON DELETE CASCADE`; `model FavoriteLink` hat zusaetzlich das RELATIONSFELD
+`widgetInstance` — die Wegwerf-Tabelle muss ueber
+`readSchemaModelScalarFieldNames('FavoriteLink')` (der Helfer aus 260911-fh9)
+verglichen werden, nicht ueber `readSchemaModelFieldNames`. `SmtpConfig`
+(20260629130000) hat 10 skalare Spalten (`id`, `tenantId`, `host`, `port`,
+`encryption`, `username`, `encryptedPassword`, `fromAddress`, `createdAt`,
+`updatedAt`) und den Eindeutigkeitsindex `SmtpConfig_tenantId_key` (Zeile
+169) — ohne diesen Index misst Pruefung 8 des settings-Abschnitts nichts.
+`updatedAt` hat in beiden Migrationen keine Vorgabe; die Wegwerf-Tabellen
+bekommen fuer die Roh-SQL-Einfuegungen `DEFAULT CURRENT_TIMESTAMP` mit
+Vermerk als Abweichung, die nur das Nachruesten betrifft (Form von
+260911-e2s/fh9).
+
+**Befund C — die Wegwerf-Tabelle `WidgetInstance` existiert bereits, ohne
+`createdAt`/`updatedAt`, mit drei Zeilen.** `runDashboardAreaChecks`
+(`rls-scratch-check.mjs:2461-2467`) legt `"WidgetInstance"` mit `id`,
+`userId`, `tenantId`, `widgetType` an und fuegt `widget-a1` (user-a1,
+TENANT-A), `widget-a2` (user-a2, TENANT-A), `widget-b1` (user-b1, TENANT-B)
+ein; der gebundene Loeschversuch unter TENANT-A auf `widget-b1` (Zeile 2687)
+trifft null Zeilen, `widget-rejected` wird abgewiesen — alle drei Zeilen
+sollten stehen, wenn der neue Abschnitt laeuft: zur Ausfuehrungszeit ueber
+die Wartungsrolle NACHMESSEN, nicht annehmen. Der Fremdschluessel der
+Wegwerf-Tabelle `FavoriteLink` zeigt auf DIESE Tabelle (WINDOWS #27:
+Relationen sind fuer die Bestandsaufnahme unsichtbar — hier wird die
+Relation deshalb ausdruecklich mitgebaut und gemessen). Der neue Abschnitt
+ist ein Blatt: NACH `runAuthAreaChecks`, VOR `runTransactionShapeMeasurement`;
+keine spaetere Pruefung setzt auf seinen Tabellen auf.
+
+**Befund D — der Startpfad, Glied fuer Glied gelesen.**
+`settings.service.ts:193` `findFirst()` ohne jede Bedingung; einziger
+Aufrufer `mail.module.ts:30` in `MailerModule.forRootAsync({ useFactory:
+async ... })` — BEIM START, vor jedem Anfragekontext, Kommentar dort:
+"findFirst — single-tenant default". Ergebnis wird zum EINEN Transport des
+`MailerService`, den `MailService.sendPasswordResetEmail` (einziger Aufrufer
+ausserhalb des Mailmoduls: `auth.service.ts:246`, `requestPasswordReset`)
+und `sendWelcomeEmail` benutzen. HEUTE bei mehreren Mandanten: der
+SMTP-Server und die Absenderadresse eines BELIEBIGEN Mandanten bedienen die
+Kennwort-Zuruecksetzungs-Mails ALLER Mandanten — Mandant B versendet ueber
+den Server von Mandant A, mit dessen Absender (das ist Nutzung fremder
+Zugangsdaten, nicht nur Sichtbarkeit; T-GWH-03). NACH DEM SCHARFSCHALTEN:
+`findFirst` liefert `null` -> `mail.module.ts` faellt auf Prioritaet 2
+(`MAIL_*`), 3 (`TESSERA_SMTP_*`), 4 (`localhost:1025`, Mailhog) zurueck ->
+`MailService` faengt jeden Transportfehler (`mail.service.ts:69-81`, T-02-12)
+und der Controller antwortet 200. Das Verstummen ist damit DOPPELT verdeckt:
+erst durch die Rueckfallkette (ein falscher, aber vorhandener Transport statt
+Leere), dann durch das absichtliche Verschlucken im Versand. Das ist die
+UNSYMMETRIE zu den beiden Praezedenzfaellen: `getAllActiveConfigs` (ldap)
+ist heute korrekt und verstummt spaeter; `loadAnyActiveConfigForScheduler`
+(dkv, #21) ist heute falsch und verstummt spaeter mit Protokollzeile; der
+Mail-Startpfad ist heute falsch und verstummt spaeter OHNE Protokollzeile,
+weil eine Rueckfallkette ihn ueberdeckt. ENTSCHEIDUNG (zur Ausfuehrungszeit
+nach der Lesung zu bestaetigen oder mit Grund zu verwerfen): EIGENER
+Ledger-Eintrag, nicht Anschluss an #21 — #21 ist gegen
+`dkv-scheduler.service.ts` gefuehrt, seine Reparatur ist die
+Mehrmandanten-Planung (Auftraege je Mandant); die Reparatur HIER ist eine
+andere Funktion mit bereits vorhandener Vorlage im Code: Transport je Versand
+aus `getDecryptedSmtpConfig(tenantId)` bauen, wie `DkvMailService` und
+`TenderMailService` es seit Phase 07/12 tun — `requestPasswordReset` kennt
+den Mandanten aus der Funktionszeile, `MailService` muesste ihn nur
+entgegennehmen. Das ist ein Feature (Umbau des Mailmoduls), NICHT dieser
+Auftrag — steht so im Auftrag und in `<hard_constraints>`. Umbenennung nach
+dem dkv-Praezedenzfall: `loadAnySmtpConfigForStartupTransport()`; kein Dokument
+unter `docs/` nennt den alten Namen (`grep -rn getStartupSmtpConfig docs`:
+null), die Phasen-Artefakte unter `.planning/phases` sind Geschichte und
+werden nicht angefasst.
+
+**Befund E — der Versandpfad und Befund K, Glied fuer Glied.**
+`tender-mail.service.ts:158` (`resolveTransport`, privat; bei `null`:
+`logger.warn(... skipping tender mail send (will retry next run))`, kein
+Wurf) und `dkv-mail.service.ts:47` (`sendExportEmail`; bei `null`: `throw new
+Error('No SMTP configuration found for tenant ...')`) rufen
+`getDecryptedSmtpConfig(tenantId)`; der Mandant kommt bei beiden aus der
+gebundenen Schleife des aufrufenden Bereichs (260909-laa, 260909-mir).
+`testSmtpConfig` ruft sie ebenfalls (Rueckgriff auf gespeicherte
+Zugangsdaten) und hat KEINEN eigenen Datenbankzugriff. Die
+Reihenfolgebedingung steht an zwei Stellen der Kritikschrift ((t4) Befund K,
+Zeile 625-634; (d4) Uebergaben-Absatz, Zeile 935-944) und NIRGENDS im
+Klassifikationsdokument (`grep -n "settings" docs/mandantentrennung-zugriffsklassifikation.md`:
+nur Uebersichtszeile 147 und Bestandsaufnahme 453). Nach diesem Plan: an
+beiden Stellen ein NACHTRAG (Form von (e) Befund D, Zeile 143-155: Original
+bleibt stehen, Nachtrag darunter), und der neue Hintergrunddienst-Absatz im
+Klassifikationsdokument sagt, dass die Bedingung mit 260911-gwh erfuellt ist.
+
+**Befund F — die Besitzpruefungen: dreimal richtig, einmal fehlend, und der
+Fremdschluessel umgeht den Zeilenschutz.** `update`, `remove`, `getIconBytes`
+tun `findUnique({ where: { id } })`, vergleichen `link.userId !== userId`, und
+schreiben/loeschen dann ueber die Kennung — nach der Bindung auf DEMSELBEN
+Klienten ist das die richtige Form (fremde Zeile: `findUnique` null ->
+`NotFoundException`; dkv Befund G — ein gebundenes UPDATE/DELETE ueber die
+Kennung allein traefe eine fremde Zeile still — greift nicht, weil die
+Vorpruefung davor steht; mit dem generierten Client wirft `delete` bei null
+Zeilen zudem P2025, Pruefung 6 misst das). `create` dagegen prueft NICHT, ob
+`dto.widgetId` dem Aufrufer gehoert: es schreibt `userId`/`tenantId` des
+Aufrufers und `widgetId` aus dem Rumpf. PostgreSQL prueft Fremdschluessel AN
+DER ZEILENSCHUTZ-REGEL VORBEI (dokumentiertes Verhalten: referentielle
+Integritaet umgeht Row Security) — ein gebundenes `create` unter TENANT-A mit
+`widgetId` eines TENANT-B-Widgets wuerde demnach GELINGEN, und der
+Unterschied zwischen "Widget existiert nicht" (FK-Verletzung, 500) und
+"existiert bei einem fremden Mandanten" (gelingt) ist ein Existenzorakel
+ueber Mandantengrenzen (T-GWH-05, medium). Pruefung 7 MISST das, statt es
+anzunehmen; faellt sie so aus, baut Aufgabe 2 einen Besitzriegel in `create`
+ein: gebundener `widgetInstance.findUnique({ where: { id: dto.widgetId },
+select: { userId: true } })` auf DEMSELBEN `tenantPrisma`, `null` oder
+fremde Benutzerkennung -> `NotFoundException('Widget not found')` (ohne
+Aussage ueber fremde Mandanten). Das fuegt ein NEUES (Datei, Modell)-Paar
+hinzu (Befund A). Faellt Pruefung 7 anders aus, gilt die Messung, der Riegel
+entfaellt, und das steht mit Belegzeile im SUMMARY.
+
+**Befund G — der Icon-Proxy erreicht die Datenbank NICHT und nimmt KEINE
+Client-URL.** `grep -n "prisma\|Prisma" icon-discovery.service.ts`: null
+Treffer; `getIconBytes` holt nur die GESPEICHERTE `iconUrl` einer Zeile, die
+der Aufrufer besitzt (T-QFIP-01, Controller `GET /favorites/:id/icon` nimmt
+nur die Kennung); `discoverFavoriteIconUrl(url)` bei `create`/`update` nimmt
+die Nutzer-URL, aber nur fuer den SSRF-gesicherten Abruf (privater
+IP-Bereich, gesperrte Hostnamen, manuelle Weiterleitung — T-08-05,
+`icon-discovery.service.spec.ts` deckt das). Mandantenbezug: keiner — die
+URL ist nicht mandantenskopiert, der Dienst haelt keinen Zustand je Mandant.
+Ergebnis: der Proxy bleibt UNVERAENDERT; in der Testdatei ist er eine
+Attrappe (`discoverFavoriteIconUrl`, `fetchIconBytes` als `vi.fn`), und der
+Test nagelt fest, dass `fetchIconBytes` mit der GESPEICHERTEN URL aufgerufen
+wird, nie mit einer aus dem Aufruf.
+
+**Befund H — die Mandantenquelle je Bereich, beide unterschiedlich und beide
+richtig.** `favorites.controller.ts` `extractContext`: `req.tenantId ??
+req.user?.tenantId` — WORTGLEICH mit `dashboard.controller.ts:44-45`, unter
+dessen Bindung `WidgetInstance` liegt. `FavoriteLink` haengt am Widget;
+wuerde `favorites` an das Claim binden (wie `auth` fuer Selbstbedienung),
+`dashboard` aber an die Guard-Kennung, laegen Widget und Link unter einem
+`x-tenant-id`-Wechsel eines SUPER_ADMIN in verschiedenen Mandanten.
+`favorites-api.ts` sendet die Kopfzeile nicht (`grep -rn "x-tenant-id"
+apps/web/src`: nur die vier Marktplatz-Stellen) — die Entscheidung haengt an
+der Bauform, nicht am heutigen Aufrufer. ENTSCHEIDUNG: `extractContext`
+bleibt, alle fuenf Aufrufe reichen `tenantId` durch; Kopfkommentar nennt den
+dashboard-Praezedenzfall und warum NICHT der auth-Praezedenzfall.
+`settings.controller.ts` liest `req.tenantId` — fuer eine
+ADMIN-Konfigurationsseite ist das die richtige Quelle (D-10: SUPER_ADMIN
+konfiguriert ueber `x-tenant-id` einen anderen Mandanten); der Controller
+bleibt UNVERAENDERT und steht nicht in der Erlaubnisliste.
+
+**Befund I — die umgekehrte Fehlerrichtung je Bereich, gelesen.**
+(1) `favorites`: `list` liefert `[]` -> `GET /favorites?widgetId=` 200 `[]`
+-> `fetchFavorites` (`favorites-api.ts:22-29`) gibt `[]` -> `favorites-widget.tsx:212-213`
+zeigt `t('favorites.empty')` = `Noch keine Favoriten.` (`de.json`, Zeile um
+219). "Zeile unsichtbar" und "nie einen gespeichert" sind fuer das Frontend
+derselbe Wert — Familie #23/#25/#26/#28. `update`/`remove`/`getIconBytes`:
+`NotFoundException('FavoriteLink not found')` 404 -> `favorites-api.ts` wirft
+`Failed to update/delete favorite` -> `catch` im Widget setzt
+`t('favorites.error')`. (2) `settings`: `getSmtpConfig` liefert `null` ->
+Controller gibt `null` zurueck -> NestJS sendet 200 mit LEEREM Rumpf (die
+Adapter-Kette aus (h3), 260911-fh9) -> `fetchSmtp` (`settings-api.ts:51-57`)
+prueft nur `404` und `!res.ok`, dann `res.json()` auf den leeren Rumpf ->
+wirft -> `smtp-settings-form.tsx:76-78` `.catch(() => { /* Silent fail */ })`
+-> leeres Formular: "SMTP nicht eingerichtet", waehrend die Zugangsdaten
+physisch da sind. Traegt der Administrator sie neu ein, laeuft `saveSmtpConfig`
+als `upsert({ where: { tenantId } })`: unter der UNGEBUNDENEN Form (heute, nach
+dem Scharfschalten) ist die Zeile unsichtbar, der Upsert versucht INSERT und
+scheitert am Eindeutigkeitsindex `SmtpConfig_tenantId_key` — die
+`dashboard`-Lehre (260910-krx: `PrismaClientUnknownRequestError`, NICHT
+P2002). Pruefung 8 misst Konstruktorname und `code` woertlich, statt sie
+vorwegzunehmen. `getDecryptedSmtpConfig` null: tender `warn` + kein Versand
+mit Wiederholung je Lauf, dkv `throw` (Befund E). (3) Startpfad: Befund D.
+Etappe-4-Vorabpruefung je Bereich: fuer einen bekannten Mandanten die
+`SmtpConfig`-Zeile ueber die Wartungsrolle lesen und den gebundenen
+`findUnique` daneben halten; fuer einen bekannten Nutzer/Widget die
+Favoritenzahl ueber die Wartungsrolle und ueber den gebundenen `findMany`.
+
+**Befund J — Testlage: eine Spec fuer den Icon-Proxy, keine fuer die beiden
+Dienste; Vorlagen stehen bereit.** `ls apps/api/src/favorites/`: nur
+`icon-discovery.service.spec.ts`; `ls apps/api/src/settings/`: keine Spec.
+Vorlagen: `calendar.service.spec.ts` (260911-cwh — Bereich ohne Testdatei,
+`makeFakePrisma` mit In-Memory-Zeilen, `__makeBoundClient`, `_applySelect`,
+`boundCallLog`), `dkv.service.spec.ts` (ungebundener Nachbau OHNE die
+Anfrage-Modelle), `dashboard.service.spec.ts:565` (Wachhund),
+`tender-mail.service.spec.ts:22-30` (`makeSettingsService`-Attrappe: zeigt,
+welche Rueckgabeform die Aufrufer erwarten — `host`, `port`, `encryption`,
+`username`, `fromAddress`, `decryptedPassword`). `nodemailer` wird in der
+neuen settings-Spec per `vi.mock('nodemailer')` ersetzt (`createTransport`
+liefert `{ verify: vi.fn(), sendMail: vi.fn() }`) — KEIN echter Transport
+(Umgebung: kein `mailhog`). `CryptoService` als Attrappe (`encrypt: (s) =>
+'enc(' + s + ')'`, `decrypt` strippt).
+
+**Befund K — kein weiterer Hintergrunddienst, keine Transaktion, keine
+Relationseinbindung — bis auf den Startpfad.** `grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout\|\$transaction(\|\$queryRaw\|\$executeRaw\|include:\|_count" apps/api/src/favorites apps/api/src/settings --include=*.ts | grep -v spec`:
+genau EIN Treffer, `icon-discovery.service.ts:255` — ein `setTimeout` fuer
+den Abbruch eines HTTP-Abrufs, kein Planer (dieselbe Form wie
+`ics.provider.ts:100` in 260911-cwh). `select:` kommt zweimal vor
+(`settings.service.ts:41`, `:78`), beide ausschliesslich skalare Felder von
+`SmtpConfig`, keine Relation (WINDOWS #27 ohne Auspraegung). Der einzige
+Hintergrund-Zugriff ist der Startpfad aus Befund D — er lebt NICHT in
+`settings`, sondern wird von `mail.module.ts` beim Start aufgerufen; als
+sechster Fall gehoert er unter `mail.module.ts` /
+`SettingsService.loadAnySmtpConfigForStartupTransport()`.
+
+**Befund L — die Buchfuehrung und ein veralteter Absatz in der Anleitung.**
+Uebersichtszeilen `favorites` (heute `| favorites | 7 | 0 | unverändert |`)
+und `settings` (`| settings | 4 | 0 | unverändert |`), Summenzeile (78/167),
+Bestandsaufnahme-Zeilen 431 und 453, Klassen-Verteilung (64 Paare,
+32/17/13/2), Hintergrunddienst-Abschnitt (Ueberschrift `## Der
+Hintergrunddienst als Falle — fünf Fälle`, Zeile 237; kein Gate ausserhalb
+des Dokuments referenziert diesen Wortlaut — `grep -rn "fünf Fälle\|fuenf
+Faelle" apps/api/src apps/api/scripts`: null), `Was diese Etappe NICHT
+entscheidet` (Zeile 486). Dazu `docs/anleitung-entwicklung.md:310-316`: der
+Absatz behauptet, Regeln laegen nur auf sieben Tabellen und `FavoriteLink`
+trage KEINE, und `DkvService.loadConfig()` nutze den ungebundenen Klienten —
+beides seit `20260909140000` (16 weitere Tabellen, gemessen: `grep -c
+"ENABLE ROW LEVEL SECURITY"` liefert 4 + 3 + 16 = 23) bzw. seit 260909-mir
+falsch. Der Absatz nennt `FavoriteLink` beim Namen und liegt damit in diesem
+Bereich; er wird in Aufgabe 3 auf den gemessenen Stand gebracht (scoped
+`Edit`, nur dieser Absatz).
+
+</planning_time_findings>
+
+<tasks>
+
+<task type="tracer">
+  <name>Aufgabe 1: Die Fehlerrichtung fuer BEIDE Bereiche MESSEN und aufschreiben — Favoritenleiste, SMTP-Zugangsdaten, Startpfad — ueber den generierten Client</name>
+  <precondition>Der lokale Datenbank-Container `tessera-ctl-db-1` laeuft; `docker inspect tessera-ctl-db-1` liefert eine Adresse. Ohne ihn kann das Wegwerf-Werkzeug nichts messen und die Aufgabe ist zu stoppen, nicht zu schaetzen.</precondition>
+  <files>apps/api/scripts/rls-scratch-check.mjs, docs/mandantentrennung-etappe2-fehlerrichtung.md</files>
+  <read_first>apps/api/src/prisma/prisma-tenant.extension.ts (Kopf VOLLSTAENDIG), apps/api/scripts/rls-scratch-check.mjs (Kopf, `report`, `forTenantQuery`, `withAdminPrisma`, `sqlStateOf`, `readRlsWidenMigrationSql`, `readRemainingTenantTablesMigrationSql`, `extractPolicySql`, `readSchemaModelScalarFieldNames`, `runDashboardAreaChecks` VOLLSTAENDIG (Anlage von "WidgetInstance", welche Zeilen am Ende stehen), `runDkvAreaChecks` (die Pruefung `dkvmoduleconfig-ungebundene-einzelabfrage-liefert-keine-zeile` als Vorbild fuer den Startpfad), `runCalendarAreaChecks` VOLLSTAENDIG (Blatt-Form, Spaltenpruefung, Client-Pruefungen), `runAuthAreaChecks` (die Client-Pruefungen mit Konstruktorname/`code`), `buildInlineExtendedClient`, `main`), apps/api/prisma/schema.prisma (model FavoriteLink, model SmtpConfig, model WidgetInstance), apps/api/prisma/migrations/20260708090000_add_favorite_link/migration.sql (VOLLSTAENDIG), apps/api/prisma/migrations/20260629130000_add_missing_tables/migration.sql (CREATE TABLE "SmtpConfig" und den Index `SmtpConfig_tenantId_key`), apps/api/prisma/migrations/20260909140000_rls_remaining_tenant_tables/migration.sql (die Bloecke FavoriteLink, SmtpConfig, WidgetInstance), apps/api/src/favorites/favorites.service.ts (VOLLSTAENDIG), apps/api/src/favorites/favorites.controller.ts (VOLLSTAENDIG), apps/api/src/favorites/icon-discovery.service.ts (Kopf, `discoverFavoriteIconUrl`, `fetchIconBytes`), apps/api/src/settings/settings.service.ts (VOLLSTAENDIG), apps/api/src/settings/settings.controller.ts (VOLLSTAENDIG), apps/api/src/mail/mail.module.ts (VOLLSTAENDIG), apps/api/src/mail/mail.service.ts (`sendPasswordResetEmail`, den `try/catch`), apps/api/src/tenders/tender-mail.service.ts (`resolveTransport`), apps/api/src/dkv/dkv-mail.service.ts (`sendExportEmail`), apps/api/src/dkv/dkv.service.ts (Kopfkommentar von `loadAnyActiveConfigForScheduler` VOLLSTAENDIG), apps/api/src/dkv/dkv-scheduler.service.ts (Kopf), apps/api/src/dashboard/dashboard.controller.ts (`extractContext`), apps/web/src/lib/favorites-api.ts, apps/web/src/components/dashboard/widgets/favorites-widget.tsx (den `useEffect` um Zeile 63 und die Leerstelle um Zeile 212), apps/web/src/lib/settings-api.ts (`fetchSmtp`), apps/web/src/components/settings/smtp-settings-form.tsx (den `useEffect` um Zeile 62), apps/web/src/messages/de.json (Schluessel `favorites.empty`), docs/mandantentrennung-etappe2-fehlerrichtung.md (Abschnitte `## Bereich dkv` (d1)-(d5) und `## Bereich auth` (h1)-(h5) vollstaendig, als Form; (t4) Befund K; (e) Befund D samt Nachtrag als Form fuer Nachtraege), .planning/WINDOWS.md (Eintrag #21 VOLLSTAENDIG)</read_first>
+  <action>
+TEIL 1 — die Messung, zwei Abschnitte. Erweitere `apps/api/scripts/rls-scratch-check.mjs`
+um `runFavoritesAreaChecks(adminUrl, scratchRoleUrl, results)` und
+`runSettingsAreaChecks(adminUrl, scratchRoleUrl, results)` und rufe beide in
+`main()` in dieser Reihenfolge NACH `runAuthAreaChecks` und VOR
+`runTransactionShapeMeasurement` auf. Beide sind Blaetter (keine spaetere
+Pruefung setzt auf ihren Tabellen auf); halte die Reihenfolgebedingung im
+Kopfkommentar fest, wie `runCalendarAreaChecks` es vormacht. Beide beginnen
+mit der Regelstand-Pruefung (die Widen-Migration darf keine eigene Regel fuer
+die Tabelle tragen — Form `calendarsource-regelstand-eindeutig`), schneiden
+die Regel WORTGLEICH aus `20260909140000_rls_remaining_tenant_tables`
+(`extractPolicySql`), legen die Wegwerf-Tabelle mit SAEMTLICHEN skalaren
+Spalten an, pruefen die Spaltenmenge zur Laufzeit gegen
+`readSchemaModelScalarFieldNames(<Modell>)` (bei `FavoriteLink` ist das
+Relationsfeld `widgetInstance` auszufiltern — deshalb der Helfer aus
+260911-fh9, nicht `readSchemaModelFieldNames`) und brechen ab, wenn die
+Spaltenpruefung durchfaellt (Form von Pruefung 8 in `runCalendarAreaChecks`).
+`updatedAt` bekommt `DEFAULT CURRENT_TIMESTAMP` als vermerkte Abweichung
+(Prisma setzt den Wert clientseitig). Alle Pruefungen laufen unter der Rolle
+ohne `BYPASSRLS`; Vergleichswerte kommen ueber die Wartungsrolle. Jede
+Pruefung hat eine Belegausgabe mit den beobachteten Werten; wo ein Fehler
+erwartet wird, Konstruktorname und `code` woertlich — rate das Ergebnis nicht
+vorweg.
+
+`runFavoritesAreaChecks` — die Wegwerf-Tabelle `"FavoriteLink"` bekommt den
+Fremdschluessel `FOREIGN KEY ("widgetId") REFERENCES "WidgetInstance"("id")
+ON DELETE CASCADE` auf die von `runDashboardAreaChecks` angelegte Tabelle
+(Befund C — vorher ueber die Wartungsrolle MESSEN, welche `WidgetInstance`-
+Zeilen stehen, und die Belegausgabe der ersten Pruefung nennt sie).
+Zeilen: `fav-a1-1`, `fav-a1-2` (user-a1, TENANT-A, widget-a1), `fav-a2-1`
+(user-a2, TENANT-A, widget-a2), `fav-b1-1` (user-b1, TENANT-B, widget-b1);
+`fav-a1-1` mit `iconUrl`, `fav-a1-2` ohne. Mindestens sieben Pruefungen:
+
+1. `favoritelink-regelstand-eindeutig`.
+2. `favoritelink-wegwerftabelle-deckt-alle-spalten-des-generierten-clients`
+   — zehn skalare Felder; die Belegausgabe nennt zusaetzlich die gemessenen
+   `WidgetInstance`-Zeilen.
+3. `favoritelink-liste-generierter-client-ungebunden-liefert-leere-liste` —
+   die tragende Belegzeile: `prisma.favoriteLink.findMany({ where: { userId:
+   'user-a1', widgetId: 'widget-a1' }, orderBy: [{ position: 'asc' }, {
+   title: 'asc' }] })` — die Form von `list` — UNGEBUNDEN: `[]`, waehrend die
+   Wartungsrolle zwei Zeilen sieht. Die Belegausgabe sagt beim Namen: das ist
+   der Wert, aus dem `favorites-widget.tsx` `Noch keine Favoriten.` macht.
+4. `favoritelink-liste-generierter-client-gebunden-eigener-mandant-liefert-eigene-zeilen`
+   — dieselbe Abfrage ueber `buildInlineExtendedClient(prisma, 'TENANT-A')`:
+   genau zwei Zeilen, beide `userId === 'user-a1'`, `widgetId === 'widget-a1'`;
+   die Zeile von `user-a2` ist NICHT dabei (die anwendungsseitige
+   Benutzerfilterung), aber — zweite Aussage derselben Messung, eigene
+   Belegausgabe — ein gebundener `findMany({ where: { widgetId: 'widget-a2' } })`
+   unter TENANT-A liefert die Zeile des Kollegen: die Regel kennt keine
+   Benutzerdimension (dieselbe Lehre wie `calendarsource-fremder-nutzer-desselben-mandanten-gebunden-sichtbar`).
+5. `favoritelink-besitzpruefung-generierter-client-gebunden-fremder-mandant-liefert-null`
+   — `findUnique({ where: { id: 'fav-a1-1' } })` gebunden unter TENANT-B:
+   `null`. Das ist die Datenbankseite der Vorpruefung in `update`/`remove`/
+   `getIconBytes` (T-GWH-02).
+6. `favoritelink-gebundenes-loeschen-ueber-kennung-allein-fremder-mandant-scheitert-laut`
+   — `delete({ where: { id: 'fav-a1-1' } })` ueber den GENERIERTEN Client
+   gebunden unter TENANT-B: bestanden genau dann, wenn ein Fehler geworfen
+   wird UND die Wartungsrolle die Zeile danach noch liest. Konstruktorname und
+   `code` woertlich (der generierte Client meldet null getroffene Zeilen bei
+   `delete` anders als Roh-SQL — dkv Befund G in der Client-Form).
+7. `favoritelink-fremdschluessel-prueft-am-zeilenschutz-vorbei` — gebundenes
+   `create` unter TENANT-A mit `data: { id: 'fav-a1-fremdes-widget', userId:
+   'user-a1', tenantId: 'TENANT-A', widgetId: 'widget-b1', title, url,
+   position: 0 }` (das Widget gehoert TENANT-B und ist unter TENANT-A
+   UNSICHTBAR — vorher mit gebundenem `widgetInstance.findUnique` messen und
+   ausgeben). Belegausgabe nennt, ob der INSERT gelang oder mit welchem
+   Konstruktor/`code` er scheiterte. Bestanden ist die Pruefung in BEIDEN
+   Faellen — sie ist eine Messung, deren Ergebnis Aufgabe 2 steuert (Befund
+   F): gelingt der INSERT, umgeht der Fremdschluessel den Zeilenschutz und
+   der Besitzriegel wird gebaut; die Zeile danach ueber die Wartungsrolle
+   wieder entfernen. Dazu: die zweite Haelfte derselben Pruefung — gebundenes
+   `create` unter TENANT-A mit `widgetId: 'widget-gibt-es-nicht'` — muss
+   scheitern (FK-Verletzung, Konstruktorname/`code` woertlich): der
+   Unterschied zwischen beiden Antworten ist das Existenzorakel (T-GWH-05).
+8. `favoritelink-gebundenes-anlegen-eigener-mandant-gelingt` — gebundenes
+   `create` unter TENANT-A mit `widgetId: 'widget-a1'` gelingt, die
+   Wartungsrolle liest die Zeile mit `tenantId === 'TENANT-A'`, `createdAt`
+   und `updatedAt` gesetzt.
+
+`runSettingsAreaChecks` — die Wegwerf-Tabelle `"SmtpConfig"` bekommt den
+Eindeutigkeitsindex `CREATE UNIQUE INDEX "SmtpConfig_tenantId_key" ON
+"SmtpConfig"("tenantId")` wortgleich aus `20260629130000` (ohne ihn misst
+Pruefung 8 nichts). Zeilen: `smtp-a` (TENANT-A, host `smtp-a.example.invalid`,
+`encryptedPassword` `enc(a-passwort-platzhalter)`, `fromAddress`
+`a@example.invalid`), `smtp-b` (TENANT-B, entsprechend). Mindestens acht
+Pruefungen:
+
+1. `smtpconfig-regelstand-eindeutig`.
+2. `smtpconfig-wegwerftabelle-deckt-alle-spalten-des-generierten-clients` —
+   zehn skalare Felder; zusaetzlich `pg_indexes` liest den Index
+   `SmtpConfig_tenantId_key` (Belegausgabe nennt `indexdef`).
+3. `smtpconfig-startpfad-generierter-client-ungebunden-liefert-null` —
+   `prisma.smtpConfig.findFirst()` OHNE Bedingung, ungebunden: `null`,
+   obwohl zwei Zeilen existieren. Die Belegausgabe sagt beim Namen: das ist
+   der Wert, mit dem `mail.module.ts` nach dem Scharfschalten auf
+   Umgebungsvariablen und zuletzt `localhost:1025` zurueckfaellt — ein
+   falscher Transport statt einer Meldung.
+4. `smtpconfig-startpfad-ueber-wartungsrolle-zieht-beliebige-zeile` — dieselbe
+   Abfrage ueber die Wartungsrolle (`BYPASSRLS`, die HEUTIGE Lage): genau
+   EINE Zeile, deren `tenantId` die Belegausgabe nennt, mit dem Satz, dass
+   nichts in der Abfrage bestimmt, WELCHER Mandant gezogen wird, und dass
+   dessen Server und Absender ab Start alle Kennwort-Zuruecksetzungs-Mails
+   ALLER Mandanten tragen (T-GWH-03).
+5. `smtpconfig-versandpfad-generierter-client-ungebunden-liefert-null` —
+   `findUnique({ where: { tenantId: 'TENANT-A' } })` ungebunden: `null`,
+   waehrend die Wartungsrolle die Zeile liest. Die Belegausgabe sagt: das ist
+   Befund K — `tender-mail.service.ts` protokolliert `No SMTP configuration`
+   und ueberspringt, `dkv-mail.service.ts` wirft; kein Versand fuer niemanden.
+6. `smtpconfig-versandpfad-generierter-client-gebunden-eigener-mandant-liefert-zugangsdaten`
+   — gebunden unter TENANT-A: Zeile mit `encryptedPassword ===
+   'enc(a-passwort-platzhalter)'`, `host`, `fromAddress` wie eingefuegt.
+7. `smtpconfig-versandpfad-generierter-client-gebunden-fremder-mandant-liefert-null`
+   — `findUnique({ where: { tenantId: 'TENANT-A' } })` gebunden unter
+   TENANT-B: `null` — die verschluesselten Zugangsdaten von A sind fuer B
+   unsichtbar (T-GWH-01).
+8. `smtpconfig-ungebundenes-upsert-auf-unsichtbare-zeile-scheitert-laut` —
+   die Form von `saveSmtpConfig`: `upsert({ where: { tenantId: 'TENANT-A' },
+   create: { id: 'smtp-a-neu', tenantId: 'TENANT-A', host:
+   'smtp-a-neu.example.invalid', fromAddress: 'a@example.invalid' }, update:
+   { host: 'smtp-a-neu.example.invalid' } })` UNGEBUNDEN: bestanden genau
+   dann, wenn ein Fehler geworfen wird UND die Wartungsrolle danach weiterhin
+   `smtp-a.example.invalid` liest. Konstruktorname und `code` woertlich; die
+   Belegausgabe haelt daneben, was 260910-krx fuer `DashboardLayout` gemessen
+   hat (`PrismaClientUnknownRequestError`), und sagt, ob es hier gleich oder
+   anders ausfaellt. Das ist die Kette "leeres Formular -> Administrator
+   traegt neu ein -> Speichern scheitert".
+9. `smtpconfig-gebundenes-upsert-eigener-mandant-aktualisiert` — dasselbe
+   `upsert` gebunden unter TENANT-A: gelingt, die Wartungsrolle liest den
+   neuen Host fuer `smtp-a`, `smtp-b` unveraendert, `updatedAt` gesetzt.
+
+Ergaenzt wird nur, gestrichen wird nicht; nenne im SUMMARY die tatsaechlich
+gezaehlte Zahl je Abschnitt.
+
+TEIL 2 — die Codeaussagen, jede mit ihrer Reichweite. Fuehre die
+Nachpruefungen aus den Befunden A, D, E, F, G, H, I, K und L tatsaechlich aus
+und notiere jeweils Anweisung oder Datei-und-Zeile: (A) die elf Rohtreffer;
+(D) die Aufrufer des Startpfads in `apps/api/src` (genau einer), die
+Rueckfallkette in `mail.module.ts` mit ihren vier Prioritaeten, der
+`try/catch` in `mail.service.ts`, die Aufrufer von `MailService` ausserhalb
+des Mailmoduls; (E) die zwei Aufrufer von `getDecryptedSmtpConfig` ausserhalb
+von `settings` und ihr Verhalten bei `null`, plus `testSmtpConfig`; (F) die
+drei Besitzpruefungen und der fehlende Widget-Riegel in `create`; (G) der
+Icon-Proxy ohne Datenbankzugriff, `getIconBytes` nimmt nur die Kennung; (H)
+`extractContext` in beiden Controllern nebeneinander, die `x-tenant-id`-
+Sender im Frontend; (I) die beiden Frontend-Ketten Glied fuer Glied; (K) die
+eine Anweisung; (L) die Zeilen der Anleitung. Faellt eine Nachpruefung ANDERS
+aus als in den Planungsbefunden, gilt die Messung — schreibe sie auf und
+benenne die Abweichung ausdruecklich.
+
+TEIL 3 — die Kritikschrift. Erweitere
+`docs/mandantentrennung-etappe2-fehlerrichtung.md` um ZWEI Abschnitte
+unmittelbar VOR `## Verweis`, in der Form der vorhandenen Bereichsabschnitte:
+`## Bereich favorites` mit (f1)-(f5) und danach `## Bereich settings` mit
+(s1)-(s5) (Buchstaben `f` und `s` sind frei — gemessen mit `grep -n "^### ("`).
+
+`## Bereich favorites`:
+- `### (f1) Die Messung` — die tatsaechlich beobachtete Werkzeugausgabe
+  woertlich eingerueckt, die tragende Belegzeile (Pruefung 3) benannt, der
+  Fremdschluessel als mitgebaute Relation (Befund C, WINDOWS #27), das
+  Ergebnis von Pruefung 7 mit dem Satz, was daraus fuer Aufgabe 2 folgt.
+- `### (f2) Signaltabelle je umzustellendem Pfad` — je Methode eine Zeile
+  (`list`, `create`, `update`, `remove`, `getIconBytes`): Verhalten nach dem
+  Scharfschalten ohne diesen Plan, konkretes Signal mit Statuscode und
+  woertlicher Meldung, ob das Frontend es durchlaesst (Datei und Zeile).
+- `### (f3) Welcher Code Leere als Abwesenheit deutet` — die Kette aus
+  Befund I (1) mit allen Gliedern, dem woertlichen Text `Noch keine
+  Favoriten.`, und dem Satz, dass "nie einen gespeichert" und "Zeile
+  unsichtbar" derselbe Wert sind (Familie #23/#25/#26/#28).
+- `### (f4) Was dieser Durchlauf bewusst nicht löst` — (a) die fehlende
+  Benutzerdimension der Regel (Kollege desselben Mandanten auf
+  Datenbankebene sichtbar; Etappe-3-Entscheidung (2)); (b) das Frontend
+  (nicht angefasst; Ledger-Eintrag in Aufgabe 3); (c) die Mandantenquelle —
+  warum der dashboard-Praezedenzfall und nicht der auth-Praezedenzfall
+  (Befund H); (d) die Etappe-4-Vorabpruefung aus Befund I.
+- `### (f5) Was dieser Durchlauf bewusst nicht anfasst` — der Icon-Proxy
+  (Befund G, mit der Messung, dass er die Datenbank nicht erreicht und keine
+  Client-URL nimmt), die DTOs, `dashboard.controller.ts` (nur gelesen), das
+  Frontend, Schema und Migrationen.
+
+`## Bereich settings`:
+- `### (s1) Die Messung` — Werkzeugausgabe woertlich, die tragenden
+  Belegzeilen (Pruefung 3 fuer den Startpfad, 5 fuer Befund K, 8 fuer den
+  Speicherkonflikt) benannt, der Eindeutigkeitsindex als Voraussetzung der
+  Konfliktmessung, das Ergebnis von Pruefung 8 neben der dashboard-Messung.
+- `### (s2) Signaltabelle je Pfad` — `getSmtpConfig`, `saveSmtpConfig`,
+  `getDecryptedSmtpConfig` (getrennt fuer den tenders- und den dkv-Aufrufer),
+  `testSmtpConfig`, und der Startpfad (mit seiner Rueckfallkette als eigener
+  Spalteninhalt): heute, nach dem Scharfschalten, Signal, Frontend.
+- `### (s3) Welcher Code Leere als Abwesenheit deutet` — die Kette aus
+  Befund I (2) mit allen Gliedern (`settings.controller.ts` gibt `null`,
+  Adapter sendet leeren Rumpf, `settings-api.ts` `res.json()` wirft,
+  `smtp-settings-form.tsx` verschluckt), der Satz, dass das Formular
+  "nicht eingerichtet" zeigt, waehrend die Zugangsdaten physisch da sind,
+  und dass ein erneutes Speichern unter der ungebundenen Form am Index
+  scheitert (Pruefung 8); die Versandpfade mit ihren zwei verschiedenen
+  Reaktionen auf `null` (warn/skip vs. throw).
+- `### (s4) Was dieser Durchlauf bewusst nicht löst` — (a) DER STARTPFAD in
+  einem eigenen Absatz, in der Form von (d4): beide Zustaende (heute:
+  beliebiger Mandant traegt alle Systemmails, T-GWH-03; nach dem
+  Scharfschalten: `null`, Rueckfallkette, `try/catch` — doppelt verdeckt),
+  die drei gepruefte Formen (binden: unmoeglich, kein Kontext beim Start;
+  Mehrmandanten-Versand: abgelehnt als Funktion, mit dem Satz, dass die
+  Vorlage — Transport je Versand aus `getDecryptedSmtpConfig(tenantId)` —
+  bereits in `DkvMailService`/`TenderMailService` steht und `MailService`
+  den Mandanten von `requestPasswordReset` bekommen koennte; Altlast mit
+  Markierung: GEWAEHLT), die UNSYMMETRIE zu `ldap` UND `dkv` (Befund D:
+  Rueckfallkette statt Leere, keine Protokollzeile), und die ENTSCHEIDUNG
+  eigener Ledger-Eintrag statt Anschluss an #21 mit Grund (andere Datei,
+  andere Reparatur, andere Verdeckungsform) — oder, falls die Lesung zur
+  Ausfuehrungszeit anders ausfaellt, die andere Entscheidung mit Grund;
+  (b) BEFUND K IST ERFUELLT — ein eigener Absatz, der sagt, dass die
+  Reihenfolgebedingung aus (t4) und (d4) mit Aufgabe 2 dieses Laufs erfuellt
+  ist, dass beide Stellen einen Nachtrag bekommen (Aufgabe 3), und dass die
+  Etappe-4-Vorabpruefung diese Bedingung NICHT mehr fuehren muss; (c) das
+  Frontend (Ledger-Eintrag in Aufgabe 3, Familie #28 — dieselbe
+  200-leerer-Rumpf-Kette); (d) die Mandantenquelle `req.tenantId` im
+  Controller als RICHTIG fuer eine ADMIN-Seite (Befund H, D-10) — bewusst
+  nicht auf das Claim umgestellt, mit dem Unterschied zu `auth`; (e) die
+  Etappe-4-Vorabpruefung.
+- `### (s5) Was dieser Durchlauf bewusst nicht anfasst` —
+  `settings.controller.ts`, das DTO, `tender-mail.service.ts`,
+  `dkv-mail.service.ts`, `mail.service.ts` (nur gelesen; `mail.module.ts`
+  wird in Aufgabe 2 fuer die Umbenennung angefasst — hier angekuendigt),
+  das Frontend, Schema und Migrationen, `nodemailer`.
+
+Aendere in dieser Aufgabe KEINE Datei unter `apps/api/src`, KEINE unter
+`apps/api/prisma` und KEINE unter `apps/web`.
+  </action>
+  <verify>
+    <automated>DB_IP=$(docker inspect tessera-ctl-db-1 --format '{{range $k,$v := .NetworkSettings.Networks}}{{$v.IPAddress}}{{end}}') && OUT=$(TESSERA_SCRATCH_ADMIN_URL="postgresql://tessera:tessera_dev@${DB_IP}:5432/postgres" node apps/api/scripts/rls-scratch-check.mjs) && echo "$OUT" && for K in favoritelink-regelstand-eindeutig favoritelink-wegwerftabelle-deckt-alle-spalten-des-generierten-clients favoritelink-liste-generierter-client-ungebunden-liefert-leere-liste favoritelink-liste-generierter-client-gebunden-eigener-mandant-liefert-eigene-zeilen favoritelink-besitzpruefung-generierter-client-gebunden-fremder-mandant-liefert-null favoritelink-gebundenes-loeschen-ueber-kennung-allein-fremder-mandant-scheitert-laut favoritelink-fremdschluessel-prueft-am-zeilenschutz-vorbei favoritelink-gebundenes-anlegen-eigener-mandant-gelingt smtpconfig-regelstand-eindeutig smtpconfig-wegwerftabelle-deckt-alle-spalten-des-generierten-clients smtpconfig-startpfad-generierter-client-ungebunden-liefert-null smtpconfig-startpfad-ueber-wartungsrolle-zieht-beliebige-zeile smtpconfig-versandpfad-generierter-client-ungebunden-liefert-null smtpconfig-versandpfad-generierter-client-gebunden-eigener-mandant-liefert-zugangsdaten smtpconfig-versandpfad-generierter-client-gebunden-fremder-mandant-liefert-null smtpconfig-ungebundenes-upsert-auf-unsichtbare-zeile-scheitert-laut smtpconfig-gebundenes-upsert-eigener-mandant-aktualisiert; do echo "$OUT" | grep -q "^$K: bestanden" || { echo "FEHLENDE ODER FEHLGESCHLAGENE PRUEFUNG: $K"; exit 1; }; done && N=$(echo "$OUT" | sed -nE 's/^Alle ([0-9]+) Pruefungen bestanden\.$/\1/p') && { test -n "$N" && test "$N" -ge 137 || { echo "PRUEFUNGSZAHL: ${N:-nicht alle bestanden}, erwartet mindestens 137 (120 bisherige plus mindestens 8 + 9 neue)"; exit 1; }; } && S=apps/api/scripts/rls-scratch-check.mjs && grep -q 'async function runFavoritesAreaChecks' "$S" && grep -q 'async function runSettingsAreaChecks' "$S" && grep -q "readSchemaModelScalarFieldNames('FavoriteLink')" "$S" && grep -q "readSchemaModelScalarFieldNames('SmtpConfig')" "$S" && grep -q 'REFERENCES "WidgetInstance"' "$S" && grep -q 'SmtpConfig_tenantId_key' "$S" && grep -q "extractPolicySql(remainingMigrationSql, 'FavoriteLink')\|extractPolicySql(.*'FavoriteLink')" "$S" && grep -q "extractPolicySql(.*'SmtpConfig')" "$S" && awk '/await runAuthAreaChecks\(/{a=NR} /await runFavoritesAreaChecks\(/{f=NR} /await runSettingsAreaChecks\(/{s=NR} /await runTransactionShapeMeasurement\(/{t=NR} END{ if(!(a&&f&&s&&t&&a<f&&f<s&&s<t)){print "REIHENFOLGE in main(): runFavoritesAreaChecks und runSettingsAreaChecks muessen nach runAuthAreaChecks und vor runTransactionShapeMeasurement stehen"; exit 1} }' "$S" && D=docs/mandantentrennung-etappe2-fehlerrichtung.md && grep -q '^## Bereich favorites$' "$D" && grep -q '^## Bereich settings$' "$D" && for X in f1 f2 f3 f4 f5 s1 s2 s3 s4 s5; do grep -qE "^### \($X\) " "$D" || { echo "FEHLENDER UNTERABSCHNITT: ($X)"; exit 1; }; done && awk '/^## Bereich favorites$/{f=1; next} /^## /{f=0} f && /Noch keine Favoriten\./{e=1} f && /favorites-widget\.tsx/{w=1} f && /favorites-api\.ts/{a=1} f && /icon-discovery\.service\.ts/{i=1} f && /WidgetInstance/{r=1} f && /dashboard\.controller\.ts/{c=1} END{ if(!e||!w||!a){print "(f3): die Frontend-Kette (favorites-widget.tsx, favorites-api.ts, Noch keine Favoriten.) ist nicht benannt"; exit 1} if(!i){print "(f5): der Icon-Proxy ist nicht benannt"; exit 1} if(!r){print "(f1): der Fremdschluessel auf WidgetInstance ist nicht benannt"; exit 1} if(!c){print "(f4): die Mandantenquelle / der dashboard-Praezedenzfall ist nicht benannt"; exit 1} }' "$D" && awk '/^## Bereich settings$/{f=1; next} /^## /{f=0} f && /mail\.module\.ts/{m=1} f && /smtp-settings-form\.tsx/{w=1} f && /settings-api\.ts/{a=1} f && /tender-mail\.service\.ts/{t=1} f && /dkv-mail\.service\.ts/{d=1} f && /Befund K/{k=1} f && /#21/{l=1} f && /SmtpConfig_tenantId_key/{u=1} f && /localhost:1025/{p=1} f && /req\.tenantId/{q=1} END{ if(!m||!p){print "(s4): der Startpfad / die Rueckfallkette (mail.module.ts, localhost:1025) ist nicht benannt"; exit 1} if(!w||!a){print "(s3): die Frontend-Kette (smtp-settings-form.tsx, settings-api.ts) ist nicht benannt"; exit 1} if(!t||!d||!k){print "(s2)/(s4): Befund K mit beiden Versandpfaden ist nicht benannt"; exit 1} if(!l){print "(s4): die Entscheidung zu WINDOWS #21 ist nicht benannt"; exit 1} if(!u){print "(s1): der Eindeutigkeitsindex ist nicht benannt"; exit 1} if(!q){print "(s4): die Mandantenquelle des Controllers ist nicht benannt"; exit 1} }' "$D" && awk '/^## Bereich settings$/{f=1} /^## Verweis$/{ if(f){ok=1} f=0 } END{ if(!ok){print "ABSCHNITT ## Bereich settings steht nicht unmittelbar vor ## Verweis"; exit 1} }' "$D" && TOUT=$(npm --prefix apps/api run test 2>&1) && echo "$TOUT" | tail -6 && T=$(echo "$TOUT" | sed -nE 's/^ *Tests +([0-9]+) passed.*/\1/p' | head -1) && { test -n "$T" && test "$T" -ge 951 || { echo "TESTZAHL: ${T:-unbekannt}, erwartet mindestens 951"; exit 1; }; } && npm --prefix apps/api run type-check && git rev-parse --verify 46f0e78 >/dev/null && PRISMA_CHANGED=$(git diff --name-only 46f0e78 -- apps/api/prisma) && { test -z "$PRISMA_CHANGED" || { printf 'SCHEMA/MIGRATION GEAENDERT — in diesem Plan verboten:\n%s\n' "$PRISMA_CHANGED"; exit 1; }; } && CHANGED=$(git diff --name-only 46f0e78) && UNEXPECTED=$(printf '%s\n' "$CHANGED" | grep -v '^$' | grep -vE '^(apps/api/scripts/rls-scratch-check\.mjs|docs/mandantentrennung-etappe2-fehlerrichtung\.md|\.planning/.*)$' || true) && { test -z "$UNEXPECTED" || { printf 'UNERWARTETE AENDERUNGEN AUSSERHALB DES PLANUMFANGS:\n%s\n' "$UNEXPECTED"; exit 1; }; }</automated>
+  </verify>
+  <done>`apps/api/scripts/rls-scratch-check.mjs` hat die Abschnitte `runFavoritesAreaChecks` und `runSettingsAreaChecks` in der richtigen Reihenfolge, mit mindestens acht bzw. neun namentlich benannten Pruefungen ueber den generierten Client an Wegwerf-Tabellen, deren Spaltenmenge zur Laufzeit gegen die skalaren Felder des Schemas geprueft wird; die `FavoriteLink`-Tabelle traegt den Fremdschluessel auf `WidgetInstance`, die `SmtpConfig`-Tabelle den Eindeutigkeitsindex; der Startpfad ist als `findFirst()` ohne Bedingung in BEIDEN Zustaenden gemessen (Wartungsrolle: beliebige Zeile; Wegwerf-Rolle: `null`), der Versandpfad als Befund K, der Speicherkonflikt mit Konstruktorname und `code` woertlich, der Fremdschluessel-Durchgriff mit Ergebnis; alle Pruefungen bestehen (mindestens 137). `docs/mandantentrennung-etappe2-fehlerrichtung.md` hat `## Bereich favorites` ((f1)-(f5)) und `## Bereich settings` ((s1)-(s5)) unmittelbar vor `## Verweis`, mit woertlicher Werkzeugausgabe, Signaltabellen, beiden Frontend-Ketten, dem Startpfad-Absatz mit beiden Zustaenden, Unsymmetrie und Ledger-Entscheidung, und dem Absatz, dass Befund K erfuellt ist. Baseline gehalten (mindestens 951 Tests, Typpruefung sauber). Unter `apps/api/src`, `apps/api/prisma`, `apps/web` und den Compose-/Umgebungsdateien ist nichts geaendert.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Aufgabe 2: Beide Dienste binden (ein Klient je Methode), den Startpfad umbenennen und markieren, den Widget-Besitzriegel einbauen, zwei neue Testdateien mit dem Zwei-Klienten-Nachbau</name>
+  <files>apps/api/src/favorites/favorites.service.ts, apps/api/src/favorites/favorites.service.spec.ts, apps/api/src/favorites/favorites.controller.ts, apps/api/src/settings/settings.service.ts, apps/api/src/settings/settings.service.spec.ts, apps/api/src/mail/mail.module.ts</files>
+  <read_first>apps/api/src/favorites/favorites.service.ts (VOLLSTAENDIG, erneut), apps/api/src/favorites/favorites.controller.ts (VOLLSTAENDIG, erneut), apps/api/src/settings/settings.service.ts (VOLLSTAENDIG, erneut), apps/api/src/mail/mail.module.ts (VOLLSTAENDIG, erneut), apps/api/src/calendar/calendar.service.spec.ts (VOLLSTAENDIG — die Vorlage fuer einen Bereich ohne Testdatei), apps/api/src/dkv/dkv.service.spec.ts (`makeFakePrisma`, `__makeBoundClient`, der Kopfkommentar zur Falsifizierung), apps/api/src/dashboard/dashboard.service.spec.ts (Zeilen 545-570, Wachhund), apps/api/src/tenders/tender-mail.service.spec.ts (Zeilen 1-60, die erwartete Rueckgabeform von `getDecryptedSmtpConfig`), apps/api/src/dkv/dkv.service.ts (Kopfkommentar von `loadAnyActiveConfigForScheduler` — die Vorlage fuer den Startpfad-Kommentar), apps/api/src/dkv/dkv-scheduler.service.ts (Kopf, Zeilen 20-35 und 80-86), apps/api/src/prisma/rls-access-inventory.spec.ts (`analyzeFile` — die Zuweisungsform `const X = forTenant(`), docs/mandantentrennung-etappe2-fehlerrichtung.md (Abschnitte `## Bereich favorites` und `## Bereich settings` aus Aufgabe 1, besonders (f1) Pruefung 7, (f4)(c), (s4)(a))</read_first>
+  <behavior>
+ZUERST die Testlage, DANN der Umbau — je Bereich eine NEUE Testdatei in der
+Form von `calendar.service.spec.ts`: `vi.mock` auf das Bindungshilfsmittel
+wird auf `prisma.__makeBoundClient(tenantId)` umgeleitet; ein handgerollter
+`makeFakePrisma()` mit In-Memory-Zeilen und Bindungsprotokoll
+`boundCallLog` (`{ tenantId, model, method }`); der UNGEBUNDENE Nachbau hat
+KEINES der Anfrage-Modelle (ein versehentlich ungebundener Modellzugriff
+scheitert mit "Cannot read properties of undefined" — die dkv-Form der
+Falsifizierung); jeder Fall eigenstaendig, jeder mit sprechendem Namen; die
+Zahl der Faelle wird am Ende ABGEZAEHLT und im SUMMARY genannt.
+
+`apps/api/src/favorites/favorites.service.spec.ts` — Zeilen fuer
+`favoriteLink` (Map ueber die Kennung, alle zehn skalaren Felder) und
+`widgetInstance` (Map ueber die Kennung: `id`, `userId`, `tenantId`,
+`widgetType`); der gebundene Klient bietet `favoriteLink.findMany` (Filter
+`where` ueber `userId`/`widgetId`, Sortierung nach `position`, dann `title`),
+`findUnique`, `create`, `update` (wirft bei unsichtbarer Zeile einen Fehler
+mit `code: 'P2025'`), `delete` (ebenso) und `widgetInstance.findUnique` (mit
+`select`); alle liefern nur Zeilen, deren `tenantId` dem Klienten entspricht.
+`IconDiscoveryService` als Attrappe: `discoverFavoriteIconUrl: vi.fn(async
+(url) => 'https://icons.invalid/' + encodeURIComponent(url))`,
+`fetchIconBytes: vi.fn(async () => ({ contentType: 'image/png', body:
+Buffer.from('png') }))`; `normalizeUrl` bleibt die ECHTE Funktion (sie ist
+rein). Faelle:
+
+- `list(t1, user-a1, widget-a1)`: liefert nur die Zeilen von `user-a1` fuer
+  `widget-a1`, sortiert nach `position` aufsteigend, bei Gleichstand nach
+  `title`; die Zeile von `user-a2` und die von `widget-a2` fehlen.
+- `list` unter FREMDEM Mandanten (`t2`, Zeilen unter `t1`): `[]` — kein
+  Fehler (das ist der Wert, aus dem das Widget `Noch keine Favoriten.`
+  macht).
+- `list` ohne `widgetId`: `BadRequestException`, KEIN Klient erzeugt.
+- `create(t1, user-a1, dto)` ohne `iconUrl`: URL normalisiert
+  (`ctl.de` -> `https://ctl.de`), Icon-Suche mit der NORMALISIERTEN URL
+  aufgerufen, gebundener `create` mit `userId`, `tenantId: 't1'`,
+  `widgetId`, `position: 0` als Vorgabe.
+- `create` mit `iconUrl`: KEINE Icon-Suche, gespeicherter Wert wie
+  uebergeben.
+- `create` mit `widgetId` eines Widgets, das einem ANDEREN Benutzer
+  desselben Mandanten gehoert: `NotFoundException` mit Meldung woertlich
+  `Widget not found`, KEIN `create`, KEINE Icon-Suche (T-GWH-05).
+- `create` mit `widgetId` eines Widgets unter FREMDEM Mandanten:
+  `NotFoundException` `Widget not found` — die Meldung nennt weder Halter
+  noch Mandanten; KEIN `create`.
+- `create` mit unbekannter `widgetId`: dieselbe `NotFoundException`.
+- `update(t1, id, user-a1, dto)`, eigene Zeile: Titel/URL/Position
+  gemergt, gebundener `update`; `iconUrl` explizit `null` im DTO -> Icon-Suche
+  gegen die EFFEKTIVE URL (neue, sonst gespeicherte); `iconUrl` gesetzt ->
+  keine Icon-Suche.
+- `update`, Zeile eines ANDEREN Benutzers desselben Mandanten:
+  `NotFoundException` `FavoriteLink not found`, KEIN Schreibzugriff.
+- `update`, Zeile unter FREMDEM Mandanten (Klient `t2`, Zeile `t1`):
+  `NotFoundException`, KEIN Schreibzugriff — der gebundene `findUnique`
+  liefert `null`, bevor irgendetwas geschrieben wird.
+- `remove`: eigene Zeile geloescht (Map leer fuer diese Kennung); fremder
+  Benutzer -> `NotFoundException`, Zeile bleibt; fremder Mandant ->
+  `NotFoundException`, Zeile bleibt.
+- `getIconBytes`: eigene Zeile mit `iconUrl` -> `fetchIconBytes` GENAU mit
+  der GESPEICHERTEN URL aufgerufen, Rueckgabe durchgereicht; Zeile ohne
+  `iconUrl` -> `NotFoundException`, `fetchIconBytes` NICHT aufgerufen;
+  fremder Mandant -> `NotFoundException`; `fetchIconBytes` wirft ->
+  `HttpException` mit Status 502.
+- Wachhund je Methode: genau EIN gebundener Klient je Aufruf
+  (`vi.mocked(forTenant).mock.calls.length`), Suche, Widget-Pruefung und
+  Schreibzugriff auf DEMSELBEN — das Protokoll zeigt fuer `create` zwei
+  Eintraege (`widgetInstance.findUnique`, `favoriteLink.create`) mit
+  derselben Mandantenkennung.
+
+`apps/api/src/settings/settings.service.spec.ts` — Zeilen fuer `smtpConfig`
+(Map ueber `tenantId`, alle zehn skalaren Felder). GRENZE als Bauform: der
+UNGEBUNDENE Nachbau bietet fuer `smtpConfig` AUSSCHLIESSLICH `findFirst`
+(der Startpfad) — kein `findUnique`, kein `upsert`; der GEBUNDENE Klient
+bietet AUSSCHLIESSLICH `findUnique` (mit `select`) und `upsert` (Merge oder
+Anlage, `select` angewandt) — KEIN `findFirst`. Damit scheitert ein
+gebundener Startpfad ebenso hart wie ein ungebundener Anfrageweg.
+`CryptoService` als Attrappe (`encrypt: vi.fn((s) => 'enc(' + s + ')')`,
+`decrypt: vi.fn((s) => s.slice(4, -1))`); `nodemailer` per
+`vi.mock('nodemailer', ...)` ersetzt: `createTransport` liefert
+`{ verify: vi.fn(async () => true), sendMail: vi.fn(async () => ({})) }`,
+konfigurierbar auf Wurf. Faelle:
+
+- `getSmtpConfig(t1)`: Zeile mit `encryptedPassword` (der Controller macht
+  daraus `hasPassword`), OHNE weitere Felder ausserhalb des `select`;
+  fremder Mandant (`t2`): `null`.
+- `saveSmtpConfig(t1, dto)` mit Kennwort: `encrypt` GENAU mit dem Klartext
+  aufgerufen; gebundener `upsert` mit `where.tenantId === 't1'`, `create`
+  und `update` tragen `encryptedPassword: 'enc(...)'`; Rueckgabe OHNE
+  `encryptedPassword` (SMTP_SAFE_SELECT); der Klartext taucht in KEINEM
+  Protokolleintrag auf.
+- `saveSmtpConfig` OHNE Kennwort (leer oder fehlend): `encrypt` NICHT
+  aufgerufen, `update` traegt KEINEN Schluessel `encryptedPassword`
+  (bestehendes bleibt), `username` fehlend -> `null`.
+- `saveSmtpConfig` unter `t2`, wenn nur `t1` eine Zeile hat: der gebundene
+  Nachbau legt fuer `t2` an (die Zeile von `t1` bleibt unveraendert) — die
+  richtige Semantik NACH der Bindung.
+- `getDecryptedSmtpConfig(t1)`: `decrypt` mit `encryptedPassword`
+  aufgerufen, Rueckgabe mit `host`, `port`, `encryption`, `username`,
+  `fromAddress`, `decryptedPassword` (genau die Form, die
+  `tender-mail.service.spec.ts` als `BASE_SMTP_CONFIG` erwartet); ohne
+  `encryptedPassword` -> `decryptedPassword: null`, `decrypt` NICHT
+  aufgerufen; fremder Mandant -> `null`, `decrypt` NICHT aufgerufen
+  (T-GWH-01).
+- `testSmtpConfig(t1, dto)` ohne Kennwort/Benutzername im DTO: greift ueber
+  den GEBUNDENEN Klienten auf die gespeicherten Werte zurueck
+  (`createTransport` mit `auth.user` aus der Zeile, `auth.pass` entschluesselt),
+  `verify` aufgerufen, `{ success: true }`; mit `testTo`: `sendMail` statt
+  `verify`, `from === dto.fromAddress`, `to === dto.testTo`; `verify` wirft ->
+  `{ success: false }`, kein Wurf nach aussen; fremder Mandant ohne
+  Kennwort im DTO: `auth` ohne Benutzer (`undefined`), kein Fehler.
+- Startpfad `loadAnySmtpConfigForStartupTransport()`: laeuft ueber den
+  UNGEBUNDENEN Nachbau (`findFirst`), liefert `{ host, port, secure,
+  requireTLS, username, password, fromAddress }` mit `secure` fuer
+  `ssl-tls` und `requireTLS` fuer `starttls`, `password` entschluesselt;
+  leerer Nachbau -> `null`; und der NULL-KLIENTEN-NACHWEIS:
+  `vi.mocked(forTenant).mock.calls.length === 0` nach dem Aufruf — der
+  Startpfad erzeugt KEINEN gebundenen Klienten, gemessen, nicht behauptet.
+- Wachhund je Anfrageweg: genau EIN gebundener Klient je Aufruf von
+  `getSmtpConfig`, `saveSmtpConfig`, `getDecryptedSmtpConfig`;
+  `testSmtpConfig` erzeugt genau einen (ueber `getDecryptedSmtpConfig`),
+  wenn es zurueckgreift, und KEINEN, wenn Kennwort und Benutzername im DTO
+  stehen.
+  </behavior>
+  <action>
+TEIL 1 — `favorites.service.ts`. Stelle alle fuenf Methoden um, je Methode
+EIN Klient in der Zuweisungsform, die `rls-access-inventory.spec.ts` erkennt:
+Konstante `tenantPrisma` aus dem Bindungshilfsmittel mit `this.prisma` und
+dem uebergebenen Mandanten, `as any`. Der Mandant wird ERSTER Parameter
+jeder Methode (Konvention der Vorgaenger): `list(tenantId, userId,
+widgetId)`, `create(tenantId, userId, dto)` (heute `create(userId,
+tenantId, dto)` — Reihenfolge tauschen, den Aufrufer mit), `update(tenantId,
+id, userId, dto)`, `remove(tenantId, id, userId)`, `getIconBytes(tenantId,
+id, userId)`. Die Besitzpruefungen (`findUnique`, Vergleich `link.userId !==
+userId`, dann `update`/`delete` ueber die Kennung) bleiben WORTGLEICH und
+laufen auf DEMSELBEN Klienten wie der Schreibzugriff. Meldungen, Sortierung,
+Normalisierung, Icon-Suche, 502-Uebersetzung bleiben WORTGLEICH.
+
+In `create`, VOR der Icon-Suche, der neue Besitzriegel (T-GWH-05, nur wenn
+Pruefung 7 aus Aufgabe 1 den Durchgriff des Fremdschluessels bestaetigt hat —
+sonst entfaellt er, mit Belegzeile im SUMMARY): `tenantPrisma.widgetInstance
+.findUnique({ where: { id: dto.widgetId }, select: { userId: true } })`; ist
+das Ergebnis `null` oder `widget.userId !== userId`, `NotFoundException`
+mit Meldung woertlich `Widget not found` — keine Aussage ueber fremde
+Mandanten oder fremde Halter, dieselbe Antwort fuer "gibt es nicht", "gehoert
+einem Kollegen" und "liegt bei einem fremden Mandanten" (das schliesst das
+Existenzorakel). Der Riegel steht VOR der Icon-Suche, damit ein fremdes
+Widget keinen Netzabruf ausloest.
+
+Kopfkommentar der Klasse: warum gebunden (260911-gwh), dass der Mandant aus
+`extractContext` des Controllers kommt (Befund H: dieselbe Quelle wie
+`dashboard`, weil der Link am Widget haengt — ausdruecklich NICHT der
+auth-Praezedenzfall, mit Grund), dass die Regel keine Benutzerdimension hat
+und die `userId`-Filter deshalb bleiben (Etappe-3-Entscheidung (2)), und
+dass der Fremdschluessel am Zeilenschutz vorbei prueft (Pruefung 7, mit
+Ergebnis) — deshalb der Riegel. Kommentare in dieser Datei duerfen den
+ungebundenen Zugriff auf das Favoritenmodell NICHT woertlich nennen (das
+Gate zaehlt ueber die ganze Datei).
+
+TEIL 2 — `favorites.controller.ts`. `extractContext` bleibt WORTGLEICH;
+alle fuenf Handler reichen `tenantId` als ersten Parameter durch —
+`list(tenantId, userId, widgetId)`, `create(tenantId, userId, dto)`,
+`getIconBytes(tenantId, id, userId)`, `update(tenantId, id, userId, dto)`,
+`remove(tenantId, id, userId)`. Kopfkommentar der Klasse ergaenzen: die
+Mandantenquelle ist die vom Guard gesetzte Anfragekennung (fuer SUPER_ADMIN
+per Kopfzeile umschaltbar), WORTGLEICH mit `dashboard.controller.ts`, weil
+`FavoriteLink` ueber `widgetId` an `WidgetInstance` haengt und beide unter
+derselben Kennung liegen muessen; das Favoriten-Frontend sendet die Kopfzeile
+heute nicht (gemessen), die Entscheidung haengt an der Bauform.
+
+TEIL 3 — `settings.service.ts`. `getSmtpConfig`, `saveSmtpConfig`,
+`getDecryptedSmtpConfig` je mit EINEM Klienten `tenantPrisma`
+(Zuweisungsform); `select`, `SMTP_SAFE_SELECT`, Verschluesselung,
+Rueckgabeformen WORTGLEICH. `testSmtpConfig` hat keinen eigenen
+Datenbankzugriff und bleibt bis auf Kommentare unveraendert.
+
+Der Startpfad: benenne `getStartupSmtpConfig()` um in
+`loadAnySmtpConfigForStartupTransport()` (dkv-Praezedenzfall: ein Name, den
+niemand fuer einen Anfrageweg haelt), lasse ihn auf `this.prisma` mit dem
+unveraenderten `findFirst()` ohne Bedingung, und schreibe den Kopfkommentar
+nach der Vorlage von `loadAnyActiveConfigForScheduler` NEU: BLEIBT bewusst
+UNGEBUNDEN (260911-gwh, sechster Fall der Hintergrunddienst-Falle); HEUTE
+bereits falsch — bei mehreren Mandanten traegt der SMTP-Server und Absender
+eines BELIEBIGEN Mandanten alle Kennwort-Zuruecksetzungs- und
+Willkommensmails (T-GWH-03); NACH DEM SCHARFSCHALTEN `null`, und
+`mail.module.ts` faellt auf Umgebungsvariablen und zuletzt `localhost:1025`
+zurueck, `MailService` faengt den Transportfehler — das Verstummen erzeugt
+KEINE Protokollzeile (die Unsymmetrie zu `ldap` UND `dkv`); binden wuerde den
+Pfad garantiert leer laufen lassen (kein Kontext beim Start); der Umbau auf
+Transport je Versand aus `getDecryptedSmtpConfig(tenantId)` — die Form, die
+`DkvMailService`/`TenderMailService` bereits haben, `MailService` muesste
+den Mandanten von `requestPasswordReset` entgegennehmen — ist eine
+Funktionsaenderung, NICHT dieser Auftrag; Verweis auf den Ledger-Eintrag
+(die Nummer vergibt erst Aufgabe 3 — hier zunaechst woertlich der
+Platzhalter `WINDOWS #TBD-GWH`, den Aufgabe 3 in DIESER Datei und in
+`mail.module.ts` durch die vergebene Nummer ersetzt; das Gate von Aufgabe 3
+zaehlt den Platzhalter auf null) und auf (s4). Kommentare in dieser Datei duerfen den ungebundenen Zugriff auf das
+SMTP-Modell nicht woertlich nennen (das Gate zaehlt genau EINE Stelle in der
+Datei — den Startpfad im Code).
+
+TEIL 4 — `mail.module.ts`. Aufruf auf den neuen Namen umstellen; den
+Modulkommentar und den Zeilenkommentar an der Aufrufstelle so umschreiben,
+dass beide Zustaende stehen (der Satz "single-tenant default" verschwindet
+und wird durch die beiden Zustaende und den Verweis auf den Ledger-Eintrag
+ersetzt). KEINE Aenderung an der Rueckfallkette selbst, KEIN Umbau des
+Transports.
+
+TEIL 5 — die beiden Testdateien aus `<behavior>`. Danach VIER
+Falsifizierungsnachweise, jeder zurueckgenommen und mit Testname und
+Fehlermeldung woertlich notiert: (a) ersetze in `list` probeweise den
+gebundenen Klienten durch den ungebundenen Basisclient —
+`favorites.service.spec.ts` wird rot (erwartete Form: der Nachbau hat kein
+ungebundenes Favoritenmodell); (b) entferne probeweise den Widget-Riegel in
+`create` — genau die drei `Widget not found`-Faelle werden rot; (c) ersetze
+in `getDecryptedSmtpConfig` probeweise den gebundenen Klienten durch den
+ungebundenen — `settings.service.spec.ts` wird rot (kein `findUnique` auf
+dem ungebundenen Nachbau); (d) binde probeweise den Startpfad — der
+Null-Klienten-Nachweis UND der Startpfad-Fall werden rot (der gebundene
+Nachbau hat kein `findFirst`). Zaehle jeweils, wie viele Faelle rot wurden,
+und nenne die Zahl.
+
+Aendere keine Datei ausserhalb der sechs genannten. Insbesondere: KEINE
+Aenderung an `settings.controller.ts`, den DTOs, `icon-discovery.service.ts`,
+`mail.service.ts`, `tender-mail.service.ts`, `dkv-mail.service.ts`,
+`dashboard.controller.ts`.
+  </action>
+  <verify>
+    <automated>npm --prefix apps/api run test -- src/favorites/favorites.service.spec.ts src/settings/settings.service.spec.ts && TOUT=$(npm --prefix apps/api run test 2>&1) && echo "$TOUT" | tail -6 && T=$(echo "$TOUT" | sed -nE 's/^ *Tests +([0-9]+) passed.*/\1/p' | head -1) && { test -n "$T" && test "$T" -gt 951 || { echo "TESTZAHL: ${T:-unbekannt}, erwartet mehr als 951"; exit 1; }; } && TF=$(echo "$TOUT" | sed -nE 's/^ *Test Files +([0-9]+) passed.*/\1/p' | head -1) && { test -n "$TF" && test "$TF" -ge 62 || { echo "TESTDATEIEN: ${TF:-unbekannt}, erwartet mindestens 62"; exit 1; }; } && npm --prefix apps/api run type-check && F=apps/api/src/favorites/favorites.service.ts && SRC=$(grep -vE '^\s*(//|\*|/\*)' "$F") && test 0 -eq "$(grep -c 'this\.prisma\.favoriteLink' "$F")" && B=$(printf '%s\n' "$SRC" | grep -o 'tenantPrisma\.favoriteLink\.' | wc -l | tr -d ' ') && { test "$B" -eq 7 || { echo "BINDUNG: $B gebundene Favoritenzugriffe, erwartet genau 7"; exit 1; }; } && C=$(printf '%s\n' "$SRC" | grep -o 'forTenant(this\.prisma, tenantId)' | wc -l | tr -d ' ') && { test "$C" -eq 5 || { echo "KLIENTEN: $C Aufrufstellen des Bindungshilfsmittels in favorites.service.ts, erwartet genau 5"; exit 1; }; } && for M in list create update remove getIconBytes; do REG=$(awk -v m="async $M(" 'index($0,m){f=1} f{print} f&&/^  \}$/{f=0}' "$F" | grep -vE '^\s*(//|\*|/\*)'); K=$(printf '%s\n' "$REG" | grep -c 'forTenant(this\.prisma, tenantId)'); test "$K" -eq 1 || { echo "METHODE $M: $K Klienten, erwartet genau 1"; exit 1; }; U=$(printf '%s\n' "$REG" | grep -c 'this\.prisma\.[a-zA-Z]'); test "$U" -eq 0 || { echo "METHODE $M: $U ungebundene Modellzugriffe"; exit 1; }; done && grep -q 'async list(tenantId: string, userId: string, widgetId: string)' "$F" && grep -q 'async create(tenantId: string, userId: string, dto: CreateFavoriteDto)' "$F" && grep -q 'Widget not found' "$F" && grep -q 'tenantPrisma\.widgetInstance\.findUnique' "$F" && G=apps/api/src/settings/settings.service.ts && GS=$(grep -vE '^\s*(//|\*|/\*)' "$G") && U2=$(printf '%s\n' "$GS" | grep -c 'this\.prisma\.smtpConfig') && { test "$U2" -eq 1 || { echo "STARTPFAD: $U2 ungebundene SMTP-Zugriffe im Code von settings.service.ts, erwartet genau 1 (nur der Startpfad)"; exit 1; }; } && test 1 -eq "$(grep -c 'this\.prisma\.smtpConfig' "$G")" && B2=$(printf '%s\n' "$GS" | grep -o 'tenantPrisma\.smtpConfig\.' | wc -l | tr -d ' ') && { test "$B2" -eq 3 || { echo "BINDUNG: $B2 gebundene SMTP-Zugriffe, erwartet genau 3"; exit 1; }; } && C2=$(printf '%s\n' "$GS" | grep -o 'forTenant(this\.prisma, tenantId)' | wc -l | tr -d ' ') && { test "$C2" -eq 3 || { echo "KLIENTEN: $C2 Aufrufstellen in settings.service.ts, erwartet genau 3"; exit 1; }; } && grep -q 'async loadAnySmtpConfigForStartupTransport()' "$G" && REG=$(awk 'index($0,"async loadAnySmtpConfigForStartupTransport("){f=1} f{print} f&&/^  \}$/{f=0}' "$G" | grep -vE '^\s*(//|\*|/\*)') && test 1 -eq "$(printf '%s\n' "$REG" | grep -c 'this\.prisma\.smtpConfig\.findFirst()')" && test 0 -eq "$(printf '%s\n' "$REG" | grep -c 'forTenant(')" && awk 'index($0,"async loadAnySmtpConfigForStartupTransport("){exit} {print}' "$G" | tail -40 | grep -q 'UNGEBUNDEN' && test 0 -eq "$(grep -rc 'getStartupSmtpConfig' apps/api/src | awk -F: '{s+=$2} END{print s}')" && grep -q 'loadAnySmtpConfigForStartupTransport()' apps/api/src/mail/mail.module.ts && test 0 -eq "$(grep -c 'single-tenant default' apps/api/src/mail/mail.module.ts)" && test 0 -eq "$(grep -c 'tenantPrisma\.findFirst\|tenantPrisma\.smtpConfig\.findFirst' "$G")" && H=apps/api/src/favorites/favorites.controller.ts && for M in 'list(tenantId, userId, widgetId)' 'create(tenantId, userId, dto)' 'getIconBytes(' 'update(tenantId, id, userId, dto)' 'remove(tenantId, id, userId)'; do grep -qF "this.favoritesService.$M" "$H" || { echo "CONTROLLER: Aufruf $M nicht in der erwarteten Form"; exit 1; }; done && grep -q 'tenantId,$' "$H" && SF=apps/api/src/favorites/favorites.service.spec.ts && grep -q '__makeBoundClient' "$SF" && grep -q 'mock.calls.length' "$SF" && grep -q 'Widget not found' "$SF" && grep -q 'fetchIconBytes' "$SF" && SS=apps/api/src/settings/settings.service.spec.ts && grep -q '__makeBoundClient' "$SS" && grep -q "vi.mock('nodemailer'" "$SS" && grep -q 'mock.calls.length' "$SS" && grep -q 'loadAnySmtpConfigForStartupTransport' "$SS" && grep -q 'toBe(0)\|toHaveLength(0)\|toEqual(0)' "$SS" && git rev-parse --verify 46f0e78 >/dev/null && PRISMA_CHANGED=$(git diff --name-only 46f0e78 -- apps/api/prisma) && { test -z "$PRISMA_CHANGED" || { printf 'SCHEMA/MIGRATION GEAENDERT:\n%s\n' "$PRISMA_CHANGED"; exit 1; }; } && CHANGED=$(git diff --name-only 46f0e78) && UNEXPECTED=$(printf '%s\n' "$CHANGED" | grep -v '^$' | grep -vE '^(apps/api/scripts/rls-scratch-check\.mjs|docs/mandantentrennung-etappe2-fehlerrichtung\.md|apps/api/src/favorites/favorites\.service\.ts|apps/api/src/favorites/favorites\.service\.spec\.ts|apps/api/src/favorites/favorites\.controller\.ts|apps/api/src/settings/settings\.service\.ts|apps/api/src/settings/settings\.service\.spec\.ts|apps/api/src/mail/mail\.module\.ts|\.planning/.*)$' || true) && { test -z "$UNEXPECTED" || { printf 'UNERWARTETE AENDERUNGEN AUSSERHALB DES PLANUMFANGS:\n%s\n' "$UNEXPECTED"; exit 1; }; }</automated>
+  </verify>
+  <done>`favorites.service.ts`: alle fuenf Methoden nehmen den Mandanten als ersten Parameter und laufen je ueber genau EINEN Klienten `tenantPrisma` (sieben gebundene Favoritenzugriffe, fuenf Aufrufstellen des Bindungshilfsmittels, ein gebundener `widgetInstance`-Lesezugriff als Besitzriegel in `create` mit `Widget not found`); kein ungebundener Favoritenzugriff, auch nicht in Kommentaren. `favorites.controller.ts` reicht `tenantId` an alle fuenf Aufrufe durch, `extractContext` unveraendert, Kopfkommentar nennt Quelle und Praezedenzfall. `settings.service.ts`: `getSmtpConfig`, `saveSmtpConfig`, `getDecryptedSmtpConfig` je ueber EINEN Klienten (drei gebundene Zugriffe, drei Aufrufstellen); der Startpfad heisst `loadAnySmtpConfigForStartupTransport()`, laeuft unveraendert auf dem ungebundenen Klienten mit `findFirst()` ohne Bedingung — die einzige ungebundene Stelle der Datei —, traegt den Kopfkommentar mit beiden Zustaenden, Unsymmetrie, Reparaturweg, Ledger-Verweis; der alte Name kommt in `apps/api/src` nicht mehr vor; `mail.module.ts` ruft den neuen Namen auf und nennt beide Zustaende statt "single-tenant default". Beide Testdateien existieren neu mit dem Zwei-Klienten-Nachbau (ungebunden ohne Anfrage-Modelle, gebunden ohne `findFirst`), jedem in `<behavior>` genannten Fall, Wachhund und Null-Klienten-Nachweis; alle vier Falsifizierungsnachweise durchgefuehrt, zurueckgenommen, woertlich notiert. Testzahl gestiegen, mindestens 62 Testdateien, Typpruefung sauber, Schema/DTOs/Controller `settings`/Icon-Proxy/Versanddienste unveraendert.</done>
+</task>
+
+<task type="auto">
+  <name>Aufgabe 3: Alle Dokumentstellen auf den Endstand der Etappe 2 bringen (sechster Fall, Befund K erfuellt, Abschluss-Abschnitt), drei Ledger-Eintraege anlegen, Nummern eintragen, Gates falsifizieren</name>
+  <files>docs/mandantentrennung-zugriffsklassifikation.md, docs/mandantentrennung-etappe2-fehlerrichtung.md, docs/anleitung-entwicklung.md, .planning/WINDOWS.md, apps/api/src/settings/settings.service.ts, apps/api/src/mail/mail.module.ts</files>
+  <read_first>docs/mandantentrennung-zugriffsklassifikation.md (VOLLSTAENDIG: Uebersichtstabelle samt Messanweisung und die Zeilen `favorites`/`settings`, Summenzeile, Klassen-Verteilung samt Tabelle, Hintergrunddienst-Abschnitt VOLLSTAENDIG (Ueberschrift, Einleitungsabsatz, der Absatz zum fuenften Fall, die Stand-Absaetze), beide Bestandsaufnahme-Zeilen, `Was diese Etappe NICHT entscheidet`), docs/mandantentrennung-etappe2-fehlerrichtung.md (Kopf (a)-(e) mit dem Nachtrag unter Befund D als Form; (t4) Befund K; (d4) Uebergaben-Absatz; die neuen Abschnitte aus Aufgabe 1; `## Verweis`), docs/anleitung-entwicklung.md (Zeilen 300-325), apps/api/src/prisma/rls-access-inventory.spec.ts (`computeStandByKey`, `parseDocEntries`), .planning/WINDOWS.md (Kopfzaehler, Eintraege #21, #25, #26, #28 als Form), .planning/quick/260911-fh9-mandantentrennung-etappe-2-bereich-auth-/260911-fh9-SUMMARY.md (wie die beiden Ledger-Eintraege dort angelegt wurden — der `gsd-tools windows append`-Aufruf), apps/api/src/settings/settings.service.ts (den Kopfkommentar des Startpfads mit dem Platzhalter), apps/api/src/mail/mail.module.ts (den Modulkommentar mit dem Platzhalter)</read_first>
+  <action>
+TEIL 1 — die Ledger-Eintraege, ueber `gsd-tools windows append` (damit
+Tabelle, JSON-Block und Kopfzaehler zusammenpassen — nicht von Hand), je mit
+`--kind`, `--phase quick-260911-gwh`, `--file`, `--description`:
+
+(1) `--kind deviation --file apps/api/src/mail/mail.module.ts` — der
+Startpfad des Mailmoduls als SECHSTER Fall der Hintergrunddienst-Falle
+(`SettingsService.loadAnySmtpConfigForStartupTransport()`, vormals mit dem
+alten Namen), BLEIBT bewusst UNGEBUNDEN. Zwei Zustaende: HEUTE bereits
+falsch — `findFirst()` ohne Bedingung zieht bei mehreren Mandanten den
+SMTP-Server und Absender EINES beliebigen Mandanten fuer alle Systemmails
+(Kennwort-Zuruecksetzung, Willkommen) ALLER Mandanten; NACH DEM
+SCHARFSCHALTEN (#18) `null`, und `mail.module.ts` faellt auf `MAIL_*`,
+`TESSERA_SMTP_*`, zuletzt `localhost:1025` zurueck, `MailService` faengt den
+Transportfehler (T-02-12) — KEINE Protokollzeile, das Verstummen ist doppelt
+verdeckt (die Unsymmetrie zu #21 und zu `getAllActiveConfigs`). Drei
+erwogene Formen wie in #21 (binden unmoeglich; Mehrmandanten-Versand
+abgelehnt als Funktion — mit dem Satz, dass die Vorlage in
+`DkvMailService`/`TenderMailService` steht und `MailService` den Mandanten
+von `requestPasswordReset` bekommen koennte; Altlast mit Markierung GEWAEHLT).
+Warum EIGENER Eintrag statt #21: andere Datei, andere Reparatur, andere
+Verdeckungsform. Markierung: umbenannte Methode mit Kopfkommentar,
+Modulkommentar in `mail.module.ts`, (s4)(a). Signal fuer das Verstummen
+gehoert in `rls-preflight.mjs` (Etappe 4). Falls die Lesung in Aufgabe 1
+(s4)(a) auf Anschluss an #21 entschieden hat, entfaellt dieser Eintrag und
+der Grund steht im SUMMARY — die Nummer im Code verweist dann auf #21.
+
+(2) `--kind deviation --file apps/web/src/components/dashboard/widgets/favorites-widget.tsx`
+— Bereich `favorites`: ein nach dem Scharfschalten zu klein gebliebenes
+Leseergebnis auf `list` sieht aus wie `Noch keine Favoriten.`
+(`favorites-widget.tsx`, Zeile um 212; `fetchFavorites` in
+`favorites-api.ts` reicht `[]` durch) — "nie einen gespeichert" und "Zeile
+unsichtbar" sind fuer das Frontend derselbe Wert; Etappe-4-Vorabpruefung
+aus (f4)(d); an dieselbe Bedingung gebunden wie #18; Familie
+#23/#25/#26/#28; das Frontend wird von 260911-gwh NICHT geaendert.
+
+(3) `--kind deviation --file apps/web/src/components/settings/smtp-settings-form.tsx`
+— Bereich `settings`: `getSmtpConfig` liefert nach dem Scharfschalten
+`null`, der Controller antwortet 200 mit leerem Rumpf, `fetchSmtp`
+(`settings-api.ts`) laeuft mit `res.json()` auf den leeren Rumpf und wirft,
+`smtp-settings-form.tsx` verschluckt das in `.catch(() => {})` — leeres
+Formular, "nicht eingerichtet", waehrend die Zugangsdaten physisch da sind;
+ein erneutes Speichern unter der ungebundenen Form scheitert am
+Eindeutigkeitsindex (Pruefung 8, mit gemessenem Konstruktor/`code`) — nach
+diesem Lauf ist `saveSmtpConfig` gebunden und trifft die eigene Zeile;
+dieselbe 200-leerer-Rumpf-Kette wie #28; Etappe-4-Vorabpruefung aus
+(s4)(e); Frontend NICHT geaendert.
+
+Pruefe nach dem Anlegen, dass jeder Eintrag in Tabelle UND JSON-Block steht
+und die Kopfzaehler (`open_count`, `total_count`) mit den Zeilen
+uebereinstimmen. Ersetze dann den Platzhalter `WINDOWS #TBD-GWH` in
+`apps/api/src/settings/settings.service.ts` und `apps/api/src/mail/mail.module.ts`
+durch die vergebene Nummer von Eintrag (1) (bzw. `#21`, falls angeschlossen)
+— sonst nichts an diesen beiden Dateien.
+
+TEIL 2 — die Klassifikation. Ziehe `docs/mandantentrennung-zugriffsklassifikation.md`
+an ALLEN handgepflegten Stellen nach, jede einzeln nachgesehen, keine
+ueberflogen (Fehler 4 des Vorhabens):
+
+1. Uebersichtszeilen `favorites` und `settings` mit den NEU GEMESSENEN Zahlen
+   aus der im Dokument genannten Messanweisung (beide Spalten), im
+   etablierten Stil mit Vermerk des vorherigen Standes (`**war 7/0**`,
+   `**war 4/0**`): fuer `favorites`, welche fuenf Methoden gebunden wurden
+   und dass der Besitzriegel einen zusaetzlichen gebundenen
+   `widgetInstance`-Lesezugriff einfuehrt (wenn gebaut — Zahl aus der
+   Messung); fuer `settings`, dass die drei Anfragewege gebunden sind und der
+   eine verbleibende ungebundene Rohtreffer der benannte Startpfad ist
+   (Verweis auf den sechsten Fall unten, den Ledger-Eintrag, (s4)(a)).
+2. Summenzeile mit fortgeschriebener Herkunftsspur (ungebunden und gebunden
+   je um die Differenzen aus Schritt 1) UND dem Satz, dass dies der Endstand
+   der Etappe 2 ist: jeder verbleibende ungebundene Rohtreffer ist einer der
+   im Dokument benannten, bewusst ungebundenen Faelle.
+3. Bestandsaufnahme: `favorites.service.ts | favoriteLink` Stand von
+   `ungebunden` auf `gebunden`, Begruendung NEU (fuenf Methoden, ein Klient je
+   Methode, Besitzpruefungen bleiben, Mandantenquelle wie `dashboard`,
+   260911-gwh); NEUE Zeile `apps/api/src/favorites/favorites.service.ts |
+   widgetInstance | muss-mandantengebunden | gebunden` mit Begruendung
+   (Besitzriegel vor dem Anlegen, weil der Fremdschluessel am Zeilenschutz
+   vorbei prueft — Pruefung 7) — NUR, wenn der Riegel gebaut wurde;
+   `settings.service.ts | smtpConfig` Stand von `ungebunden` auf `gemischt`,
+   Begruendung NEU in der Form der `dkv.service.ts`/`dkvModuleConfig`-Zeile
+   (die Mischung stammt ausschliesslich vom benannten Startpfad, keine
+   uebersehene Fundstelle; Befund K erfuellt). Ohne Schritt 3 ist
+   `rls-access-inventory.spec.ts` am Ende dieser Aufgabe rot (Stand-Vergleich
+   und, bei neuer Fundstelle, Vollstaendigkeit).
+4. Klassen-Verteilung: ein `**Stand 260911-gwh (Aufgabe 3):**`-Absatz — bei
+   gebautem Riegel: 65 Paare, eine neue Fundstelle
+   (`favorites.service.ts`/`widgetInstance`, `muss-mandantengebunden`), die
+   Zahl der Ausgabe der Pruefung entnommen, Tabelle `muss-mandantengebunden`
+   33 und Summe 65, Ueberschrift auf 65 Paare; sonst der
+   "unveraendert, ausdruecklich festgehalten"-Absatz in der Form von
+   260911-fh9. In beiden Faellen der Satz, dass zwei Paare nur ihre
+   Stand-Spalte aendern, und dass dies der Endstand der Etappe 2 ist.
+5. Hintergrunddienst-Abschnitt: Ueberschrift von `fünf Fälle` auf `sechs
+   Fälle`; im Einleitungsabsatz der Satz, dass der sechste Fall (seit
+   260911-gwh) von derselben Bauart wie der fuenfte ist; ein NEUER Absatz
+   `**Der sechste Fall, gleicher Bauart wie der fünfte — `mail.module.ts` /
+   `SettingsService.loadAnySmtpConfigForStartupTransport()`** (260911-gwh,
+   Befund D, WINDOWS #<Nr.>): offen, als benannte Altlast weitergeführt.`
+   unmittelbar NACH dem Absatz zum fuenften Fall und VOR dem
+   `**Stand 260910-exd**`-Absatz, in dessen Form: beide Zustaende, warum
+   Binden keine Loesung ist, warum der Umbau eine Funktion ist, die
+   Unsymmetrie zu BEIDEN Praezedenzfaellen (Rueckfallkette, keine
+   Protokollzeile), die dreifache Markierung, das Signal fuer
+   `rls-preflight.mjs`, UND der Satz, dass die Reihenfolgebedingung Befund K
+   (`tenders` (t4), `dkv` (d4)) fuer den VERSANDPFAD `getDecryptedSmtpConfig`
+   mit diesem Lauf ERFUELLT ist — die Etappe-4-Vorabpruefung fuehrt sie nicht
+   mehr. Dazu ein PLAIN-Absatz `**Stand 260911-gwh — der Bereich `favorites`
+   fügt diesem Abschnitt keinen weiteren Fall hinzu, gemessen statt
+   angenommen (Befund K).**` mit der Anweisung und dem `setTimeout`-Treffer
+   im Icon-Proxy (Form von 260911-cwh).
+6. Abschnitt `Was diese Etappe NICHT entscheidet`: ein NEUER Punkt — wie
+   das Mailmodul kuenftig je Mandant versendet (Transport je Versand aus
+   `getDecryptedSmtpConfig(tenantId)`, Vorlage `DkvMailService`/
+   `TenderMailService`; `MailService` braucht dafuer den Mandanten, den
+   `requestPasswordReset` aus der Funktionszeile hat) — eine Funktion,
+   Verweis auf (s4)(a) und den Ledger-Eintrag; und ein ZWEITER Punkt in der
+   durchgestrichenen Form (`~~...~~ **Aufgelöst (260911-gwh):**`) NUR, wenn
+   der Abschnitt heute einen Punkt zur settings-Reihenfolgebedingung fuehrt
+   (gemessen: keinen — dann stattdessen ein Satz am Ende des neuen
+   Hintergrunddienst-Absatzes, wie in Schritt 5 verlangt).
+
+TEIL 3 — die Kritikschrift. (a) Nachtrag unter Befund K in (t4), in der
+Form des Nachtrags unter Befund D in (e): Original bleibt stehen, darunter
+ein Absatz `**Nachtrag (260911-gwh):**` — `getDecryptedSmtpConfig(tenantId)`
+laeuft seit Aufgabe 2 dieses Laufs ueber `forTenant()`, die
+Reihenfolgebedingung ist erfuellt, Verweis auf (s4)(b) und die
+Bestandsaufnahme-Zeile `settings.service.ts`/`smtpConfig`. (b) Derselbe
+Nachtrag unter dem Uebergaben-Absatz in (d4) (nur der `settings`-Teil;
+`dkv.seed.ts`/`module-registry` ist seit 260910-exd gebunden — pruefen und,
+falls zutreffend, in demselben Nachtrag mit einem Satz nennen). (c) Ein
+NEUER Abschnitt `## Etappe 2 — Abschluss` unmittelbar NACH `## Bereich
+settings` und VOR `## Verweis`: was Etappe 2 in Summe geliefert hat — die
+Zahl der Laeufe (aus STATE.md gezaehlt: zwoelf Bereichs-/Regel-Laeufe von
+260909-ipc bis 260911-gwh, nachzaehlen), die Summenzeile der
+Uebersichtstabelle VORHER (aus dem Klassifikationsdokument: der `**war
+...**`-Ausgangswert, 227 Rohtreffer laut Kopf) und NACHHER (die Summenzeile
+nach Schritt 2 oben, woertlich abgeleitet), die Zahl der Paare und die
+Klassen-Verteilung (aus Schritt 4), die Liste der BEWUSST ungebundenen
+Reste je Bereich mit ihrem Grund in je einem Satz (tenders: D-03-Katalog,
+Fan-out-Adapter, RSS-Verwaltung #24, uebergreifende Haelften; ldap:
+`getAllActiveConfigs`, `resolveEmailForWrite`; dkv: #21; user:
+`findByUsername`, Erstanlage, Treiber; module-registry/dashboard:
+Modulkatalog; auth: drei Anmeldefunktionen; tenant: die Mandantentabelle;
+settings: der sechste Fall) — jeden Bereich aus seinem eigenen Abschnitt
+dieses Dokuments bzw. der Uebersichtszeile abgeschrieben, nicht aus dem
+Gedaechtnis —, die Zahl der offenen Ledger-Eintraege dieser Etappe (aus
+WINDOWS.md gezaehlt, mit Nummern), die Zahl der Pruefungen des Werkzeugs
+(die Zeile `Alle N Pruefungen bestanden.` des letzten Laufs) und der Tests
+(letzte Testausgabe). Dann, was fuer Etappe 3 bleibt, je ein Satz mit
+Verweis auf die Stelle: Anmeldeweg unter je Mandant eindeutigen Namen
+((h4)(a)); Benutzerdimension der Regeln (Etappe-3-Entscheidung (2), (k4)/
+(f4)); Modulkatalog-Regel (Befund E `module-registry`); Kennzeichnung der
+`bewusst-uebergreifend`-Stellen; Mandantenwechsel im Digest ((t4)). Und was
+Etappe 4 VOR dem Scharfschalten pruefen muss (`rls-preflight.mjs`): die in
+den Bereichsabschnitten benannten Vorabpruefungen, als Liste mit Verweis —
+OHNE die erfuellte Befund-K-Bedingung.
+
+TEIL 4 — die Anleitung. Bringe in `docs/anleitung-entwicklung.md` den
+Absatz um Zeile 310-316 (`app.current_tenant` wird von Postgres
+Row-Level-Security ausgewertet ...) und den Folgeabsatz (`Was ein Entwickler
+nie vergessen darf`) mit scoped `Edit` auf den gemessenen Stand: die Regeln
+liegen seit `20260909140000_rls_remaining_tenant_tables` auf 23 Tabellen
+(`grep -c "ENABLE ROW LEVEL SECURITY"` ueber die drei Migrationen, zur
+Ausfuehrungszeit gezaehlt), `FavoriteLink` und `SmtpConfig` eingeschlossen;
+die Tabellen OHNE Regel sind die im Klassifikationsdokument als
+`keine-mandantengebundene-tabelle` gefuehrten (`Tenant`, `Module`,
+`Tender`, ... — aus der Bestandsaufnahme ableiten, nicht raten);
+`DkvService.loadConfig()` ist seit 260909-mir gebunden — das Beispiel fuer
+"manuelles `tenantId`-Filter" ersetzen durch die tatsaechliche Regel: jeder
+Zugriff auf eine mandantengebundene Tabelle laeuft ueber einen dienst-intern
+mit `forTenant()` gebundenen Klienten `tenantPrisma`, die `where`-Filter
+ueber `userId` bleiben zusaetzlich; Verweis auf die beiden
+Mandantentrennungs-Dokumente. Nichts sonst in dieser Datei.
+
+TEIL 5 — zwei Falsifizierungsnachweise fuer die Dokument-Gates, jeder
+zurueckgenommen und mit Meldung woertlich notiert: (a) setze die
+Bestandsaufnahme-Zeile `favorites.service.ts | favoriteLink` probeweise
+zurueck auf `ungebunden` — `rls-access-inventory.spec.ts` muss rot werden;
+(b) setze die Uebersichtszeile `settings` probeweise auf eine falsche Zahl —
+das herleitende Gate dieser Aufgabe muss fehlschlagen.
+
+Aendere keine Datei ausserhalb der sechs genannten.
+  </action>
+  <verify>
+    <automated>DB_IP=$(docker inspect tessera-ctl-db-1 --format '{{range $k,$v := .NetworkSettings.Networks}}{{$v.IPAddress}}{{end}}') && SOUT=$(TESSERA_SCRATCH_ADMIN_URL="postgresql://tessera:tessera_dev@${DB_IP}:5432/postgres" node apps/api/scripts/rls-scratch-check.mjs) && echo "$SOUT" | tail -1 && N=$(echo "$SOUT" | sed -nE 's/^Alle ([0-9]+) Pruefungen bestanden\.$/\1/p') && { test -n "$N" && test "$N" -ge 137 || { echo "WERKZEUG: ${N:-nicht alle} Pruefungen bestanden, erwartet mindestens 137"; exit 1; }; } && npm --prefix apps/api run test -- src/prisma/rls-access-inventory.spec.ts && TOUT=$(npm --prefix apps/api run test 2>&1) && echo "$TOUT" | tail -6 && T=$(echo "$TOUT" | sed -nE 's/^ *Tests +([0-9]+) passed.*/\1/p' | head -1) && { test -n "$T" && test "$T" -gt 951 || { echo "TESTZAHL: ${T:-unbekannt}, erwartet mehr als 951"; exit 1; }; } && npm --prefix apps/api run type-check && test 0 -eq "$(grep -rc 'TBD-GWH' apps/api/src docs | awk -F: '{s+=$2} END{print s}')" && grep -qE 'WINDOWS #[0-9]+' apps/api/src/settings/settings.service.ts && grep -qE 'WINDOWS #[0-9]+' apps/api/src/mail/mail.module.ts && K=docs/mandantentrennung-zugriffsklassifikation.md && FU=$(grep -ro "this\.prisma\.[a-zA-Z]*" apps/api/src/favorites | grep -v spec | wc -l | tr -d ' ') && FB=$(grep -ro "tenantPrisma\.[a-zA-Z]*\." apps/api/src/favorites | grep -v spec | wc -l | tr -d ' ') && SU=$(grep -ro "this\.prisma\.[a-zA-Z]*" apps/api/src/settings | grep -v spec | wc -l | tr -d ' ') && SB=$(grep -ro "tenantPrisma\.[a-zA-Z]*\." apps/api/src/settings | grep -v spec | wc -l | tr -d ' ') && { test "$FU" -eq 0 || { echo "favorites: $FU ungebundene Rohtreffer, erwartet 0"; exit 1; }; } && { test "$FB" -ge 7 || { echo "favorites: $FB gebundene Rohtreffer, erwartet mindestens 7"; exit 1; }; } && { test "$SU" -eq 1 || { echo "settings: $SU ungebundene Rohtreffer, erwartet 1"; exit 1; }; } && { test "$SB" -eq 3 || { echo "settings: $SB gebundene Rohtreffer, erwartet 3"; exit 1; }; } && { grep -qE "^\| favorites \| ${FU} \| ${FB} \| \*\*war 7/0\*\*" "$K" || { echo "UEBERSICHTSZEILE favorites nennt nicht ${FU}/${FB} im etablierten Stil"; exit 1; }; } && { grep -qE "^\| settings \| ${SU} \| ${SB} \| \*\*war 4/0\*\*" "$K" || { echo "UEBERSICHTSZEILE settings nennt nicht ${SU}/${SB} im etablierten Stil"; exit 1; }; } && TU=0 && TB=0 && for d in apps/api/src/*/; do u=$(grep -ro "this\.prisma\.[a-zA-Z]*" "$d" 2>/dev/null | grep -v spec | wc -l | tr -d ' '); b=$(grep -ro "tenantPrisma\.[a-zA-Z]*\." "$d" 2>/dev/null | grep -v spec | wc -l | tr -d ' '); TU=$((TU+u)); TB=$((TB+b)); done && { grep -qE "^\| \*\*Summe\*\* \| \*\*${TU}\*\* \| \*\*${TB}\*\* \|" "$K" || { echo "SUMMENZEILE nennt nicht die abgeleiteten Werte ${TU}/${TB}"; exit 1; }; } && grep -qE '^\| apps/api/src/favorites/favorites\.service\.ts \| favoriteLink \| muss-mandantengebunden \| gebunden \|' "$K" && grep -qE '^\| apps/api/src/settings/settings\.service\.ts \| smtpConfig \| muss-mandantengebunden \| gemischt \|' "$K" && { if grep -q 'tenantPrisma\.widgetInstance\.' apps/api/src/favorites/favorites.service.ts; then grep -qE '^\| apps/api/src/favorites/favorites\.service\.ts \| widgetInstance \| muss-mandantengebunden \| gebunden \|' "$K" || { echo "BESTANDSAUFNAHME: neue Zeile favorites.service.ts/widgetInstance fehlt"; exit 1; }; fi; } && P=$(grep -cE '^\| apps/api/src/[^|]+ \| [a-zA-Z]+ \| (muss-mandantengebunden|bewusst-uebergreifend|keine-mandantengebundene-tabelle|beides) \| (gebunden|ungebunden|gemischt) \|' "$K") && { grep -qE "^## Klassen-Verteilung \(nach \(Datei, Modell\)-Fundstellen, ${P} Paare\)" "$K" || { echo "KLASSEN-VERTEILUNG: Ueberschrift nennt nicht die gezaehlten ${P} Paare"; exit 1; }; } && { grep -qE "^\| \*\*Summe\*\* \| \*\*${P}\*\* \|$" "$K" || { echo "KLASSEN-VERTEILUNG: Summe nennt nicht ${P}"; exit 1; }; } && MM=$(grep -cE '^\| apps/api/src/[^|]+ \| [a-zA-Z]+ \| muss-mandantengebunden \|' "$K") && { grep -qE "^\| muss-mandantengebunden \| ${MM} \|$" "$K" || { echo "KLASSEN-VERTEILUNG: muss-mandantengebunden nennt nicht ${MM}"; exit 1; }; } && grep -q '^\*\*Stand 260911-gwh (Aufgabe 3)' "$K" && grep -q '^## Der Hintergrunddienst als Falle — sechs Fälle$' "$K" && test 0 -eq "$(grep -c 'fünf Fälle' "$K")" && awk '/^## Der Hintergrunddienst als Falle/{f=1; next} /^## /{f=0} f && /sechste Fall/{s=1} f && /loadAnySmtpConfigForStartupTransport/{m=1} f && /mail\.module\.ts/{o=1} f && /Befund K/{k=1} f && /favorites/{v=1} f && /localhost:1025|Rückfallkette|Rueckfallkette/{r=1} END{ if(!s||!m||!o){print "HINTERGRUNDDIENST: der sechste Fall (mail.module.ts / loadAnySmtpConfigForStartupTransport) fehlt"; exit 1} if(!k){print "HINTERGRUNDDIENST: die erfuellte Befund-K-Bedingung ist nicht benannt"; exit 1} if(!v){print "HINTERGRUNDDIENST: der favorites-Absatz fehlt"; exit 1} if(!r){print "HINTERGRUNDDIENST: die Rueckfallkette ist nicht benannt"; exit 1} }' "$K" && awk '/^## Was diese Etappe NICHT entscheidet/{f=1; next} /^## /{f=0} f && /getDecryptedSmtpConfig/{g=1} f && /260911-gwh/{w=1} END{ if(!g||!w){print "NICHT ENTSCHEIDET: der Punkt zum Mehrmandanten-Versand (260911-gwh) fehlt"; exit 1} }' "$K" && D=docs/mandantentrennung-etappe2-fehlerrichtung.md && grep -q '^## Etappe 2 — Abschluss$' "$D" && awk '/^## Bereich settings$/{s=NR} /^## Etappe 2 — Abschluss$/{a=NR} /^## Verweis$/{v=NR} END{ if(!(s&&a&&v&&s<a&&a<v)){print "ABSCHLUSS-ABSCHNITT steht nicht zwischen Bereich settings und Verweis"; exit 1} }' "$D" && awk -v tu="$TU" -v tb="$TB" -v p="$P" '/^## Etappe 2 — Abschluss$/{f=1; next} /^## /{f=0} f && index($0, tu){u=1} f && index($0, tb){b=1} f && index($0, p " Paare"){q=1} f && /rls-preflight\.mjs/{r=1} f && /Etappe 3/{e=1} f && /WINDOWS/{w=1} END{ if(!u||!b){print "ABSCHLUSS: die abgeleitete Summenzeile (" tu "/" tb ") ist nicht genannt"; exit 1} if(!q){print "ABSCHLUSS: die Paarzahl (" p " Paare) ist nicht genannt"; exit 1} if(!r||!e||!w){print "ABSCHLUSS: Etappe 3, rls-preflight.mjs oder die Ledger-Eintraege sind nicht genannt"; exit 1} }' "$D" && awk '/^### \(t4\)/{f=1} /^### \(t5\)/{f=0} f && /Nachtrag \(260911-gwh\)/{n=1} END{ if(!n){print "(t4): Nachtrag unter Befund K fehlt"; exit 1} }' "$D" && awk '/^### \(d4\)/{f=1} /^### \(d5\)/{f=0} f && /Nachtrag \(260911-gwh\)/{n=1} END{ if(!n){print "(d4): Nachtrag im Uebergaben-Absatz fehlt"; exit 1} }' "$D" && A=docs/anleitung-entwicklung.md && test 0 -eq "$(grep -c 'FavoriteLink` — tragen zwar eine `tenantId`-Spalte, aber \*\*keine\*\*' "$A")" && test 0 -eq "$(grep -c 'nutzt den plain, UNGEBUNDENEN' "$A")" && grep -q '20260909140000_rls_remaining_tenant_tables' "$A" && grep -q 'tenantPrisma' "$A" && W=.planning/WINDOWS.md && OC=$(sed -nE 's/^open_count: ([0-9]+)$/\1/p' "$W") && TC=$(sed -nE 's/^total_count: ([0-9]+)$/\1/p' "$W") && ROWS=$(grep -cE '^\| [0-9]+ \| ' "$W") && { test "$ROWS" -eq "$TC" || { echo "WINDOWS: total_count=$TC, Tabellenzeilen=$ROWS"; exit 1; }; } && OPENROWS=$(grep -E '^\| [0-9]+ \| ' "$W" | grep -c '| open |') && { test "$OPENROWS" -eq "$OC" || { echo "WINDOWS: open_count=$OC, offene Zeilen=$OPENROWS"; exit 1; }; } && test "$(grep -cE '^\| [0-9]+ \| quick-260911-gwh \|' "$W")" -ge 2 && grep -q 'favorites-widget\.tsx' "$W" && grep -q 'smtp-settings-form\.tsx' "$W" && git rev-parse --verify 46f0e78 >/dev/null && PRISMA_CHANGED=$(git diff --name-only 46f0e78 -- apps/api/prisma) && { test -z "$PRISMA_CHANGED" || { printf 'SCHEMA/MIGRATION GEAENDERT:\n%s\n' "$PRISMA_CHANGED"; exit 1; }; } && CHANGED=$(git diff --name-only 46f0e78) && UNEXPECTED=$(printf '%s\n' "$CHANGED" | grep -v '^$' | grep -vE '^(apps/api/scripts/rls-scratch-check\.mjs|docs/mandantentrennung-etappe2-fehlerrichtung\.md|docs/mandantentrennung-zugriffsklassifikation\.md|docs/anleitung-entwicklung\.md|apps/api/src/favorites/favorites\.service\.ts|apps/api/src/favorites/favorites\.service\.spec\.ts|apps/api/src/favorites/favorites\.controller\.ts|apps/api/src/settings/settings\.service\.ts|apps/api/src/settings/settings\.service\.spec\.ts|apps/api/src/mail/mail\.module\.ts|\.planning/.*)$' || true) && { test -z "$UNEXPECTED" || { printf 'UNERWARTETE AENDERUNGEN AUSSERHALB DES PLANUMFANGS:\n%s\n' "$UNEXPECTED"; exit 1; }; } && test -z "$(git diff --name-only 46f0e78 -- docker-compose.yml docker-compose.*.yml .env .env.* apps/api/.env apps/api/.env.* 2>/dev/null)"</automated>
+  </verify>
+  <done>Drei neue offene Ledger-Eintraege (Startpfad des Mailmoduls — oder, mit Grund, Anschluss an #21 —, verschluckte Leere `favorites`, verschluckte Leere `settings`) stehen in Tabelle UND JSON-Block, die Kopfzaehler stimmen, der Platzhalter im Code ist durch die vergebene Nummer ersetzt. Alle handgepflegten Stellen von `docs/mandantentrennung-zugriffsklassifikation.md` sind nachgezogen und DERIVIERT gegatet: Uebersichtszeilen `favorites`/`settings` mit neu gemessenen Zahlen, Summenzeile aus der Messanweisung, Bestandsaufnahme (`favoriteLink` gebunden, `smtpConfig` gemischt, `widgetInstance` neu falls gebaut), Klassen-Verteilung mit Stand-Vermerk und aus der Tabelle gezaehlter Paarzahl, Hintergrunddienst-Abschnitt mit sechstem Fall, angepasster Ueberschrift, erfuellter Befund-K-Bedingung und favorites-Absatz, `Was diese Etappe NICHT entscheidet` mit dem Mehrmandanten-Versand-Punkt. Die Kritikschrift traegt die Nachtraege in (t4) und (d4) und den Abschnitt `## Etappe 2 — Abschluss` mit den aus den eigenen Messanweisungen abgeleiteten Zahlen, den bewusst ungebundenen Resten je Bereich, den Ledger-Nummern, dem Etappe-3-Rest und der Etappe-4-Vorabpruefliste. Die Anleitung nennt `FavoriteLink` nicht mehr als Tabelle ohne Regel und `loadConfig()` nicht mehr als ungebunden. Beide Dokument-Falsifizierungen durchgefuehrt, zurueckgenommen, woertlich notiert. Werkzeug alle Pruefungen bestanden (mindestens 137), Testzahl ueber 951, Typpruefung sauber, Schalter aus, Schema/Migrationen/Compose/Umgebung unveraendert, Erlaubnisliste gegen `46f0e78` gehalten.</done>
+</task>
+
+</tasks>
+
+<threat_model>
+
+Konfiguriert: ASVS-Stufe 1, blockierend ab `high`.
+
+## Trust Boundaries
+
+| Boundary | Description |
+|----------|-------------|
+| Angemeldeter Benutzer -> `/favorites` (`list`, `create`, `update`, `remove`, `:id/icon`) | Kennung im Pfad und `widgetId` im Rumpf sind frei waehlbare Eingaben; der Mandant kommt aus `extractContext` (Guard-Kennung, wie `dashboard`), die Benutzerkennung aus dem Sitzungsnachweis. Die Regel auf `FavoriteLink` kennt keine Benutzerdimension. |
+| `FavoriteLink.widgetId` -> `WidgetInstance.id` (Fremdschluessel) | PostgreSQL prueft referentielle Integritaet AM ZEILENSCHUTZ VORBEI: ein Bezug auf ein unsichtbares Widget wird auf Datenbankebene nicht gesperrt (Pruefung 7 misst). |
+| Favoriten-Dienst -> Icon-Proxy -> Internet | `discoverFavoriteIconUrl` nimmt die Nutzer-URL fuer einen SSRF-gesicherten Abruf (T-08-05); `fetchIconBytes` nimmt NUR die gespeicherte URL einer Zeile, die der Aufrufer besitzt (T-QFIP-01). Kein Datenbankzugriff, kein Mandantenzustand. |
+| ADMIN / SUPER_ADMIN -> `/settings/smtp` | `req.tenantId` (fuer SUPER_ADMIN per `x-tenant-id` umschaltbar) ist hier die GEWOLLTE Quelle (D-10); Zugangsdaten verschluesselt (AES-256-GCM), nie im GET. |
+| `tender-mail.service.ts` / `dkv-mail.service.ts` -> `getDecryptedSmtpConfig(tenantId)` | Der Mandant kommt aus der gebundenen Schleife des Aufrufers; der entschluesselte Wert lebt nur im Methodenrumpf (T-07-10). |
+| `mail.module.ts` (Start) -> Startpfad -> `MailerService` | Kein Mandantenkontext; eine BELIEBIGE Zeile wird zum Transport ALLER Systemmails; nach dem Scharfschalten `null` -> Rueckfallkette -> `localhost:1025`. |
+| API -> PostgreSQL, Tabellen `FavoriteLink`/`SmtpConfig` | Regel `"tenantId" = current_tenant_id()` (20260909140000); nach dem Scharfschalten liefert ein ungebundener Zugriff null Zeilen (Pruefungen 3/5), ein ungebundenes `upsert` scheitert am Eindeutigkeitsindex (Pruefung 8). |
+
+## STRIDE Threat Register
+
+| Threat ID | Category | Component | Severity | Disposition | Mitigation Plan |
+|-----------|----------|-----------|----------|-------------|-----------------|
+| T-GWH-01 | Information Disclosure | `settings.service.ts` `getSmtpConfig`/`getDecryptedSmtpConfig`, Mandantengrenze | high | mitigate | Ohne Bindung liest ein ADMIN von Mandant A ueber eine gefaelschte oder falsch aufgeloeste Mandantenkennung die (verschluesselten bzw. entschluesselten) SMTP-Zugangsdaten von B; nach dem Scharfschalten sind ungebundene Zugriffe leer statt fremd. Gebundener Klient je Methode; Pruefung 7 (fremder Mandant: `null`) ueber den generierten Client; Testfaelle (fremder Mandant: `null`, `decrypt` nicht aufgerufen); Falsifizierung (c). |
+| T-GWH-02 | Tampering / Elevation of Privilege | `favorites.service.ts` `update`/`remove`/`getIconBytes`, Mandantengrenze | high | mitigate | Ein Nutzer von Mandant A aendert oder loescht ueber die Kennung eine Favoritenzeile von Mandant B. Heute schuetzt nur der `userId`-Vergleich; nach der Bindung liefert die Vorpruefung `null` (Pruefung 5), ein gebundenes `delete` ueber die Kennung allein wirft (Pruefung 6). Beide Zugriffe auf DEMSELBEN Klienten; Testfaelle (fremder Mandant: `NotFoundException`, kein Schreibzugriff); Falsifizierung (a). |
+| T-GWH-03 | Elevation of Privilege / Information Disclosure | `mail.module.ts` Startpfad, Nutzung fremder Zugangsdaten | high | transfer | HEUTE bei mehreren Mandanten: der SMTP-Server und Absender EINES beliebigen Mandanten tragen Kennwort-Zuruecksetzungs- und Willkommensmails ALLER Mandanten (Nutzung fremder Zugangsdaten, Absenderfaelschung aus Sicht des Empfaengers). Kein Bindungsproblem — beim Start gibt es keinen Mandanten; der Umbau auf Transport je Versand ist eine Funktion (Vorlage: `DkvMailService`/`TenderMailService`). Gemessen (Pruefung 4), benannt (Kopfkommentar beider Zustaende, (s4)(a)), als OFFENER Ledger-Eintrag mit konkretem Reparaturweg uebergeben. Heute ein Mandant — die Bedingung tritt mit dem zweiten ein. |
+| T-GWH-04 | Denial of Service (still) | `mail.module.ts` Rueckfallkette nach dem Scharfschalten | high | transfer | `null` -> `MAIL_*` -> `TESSERA_SMTP_*` -> `localhost:1025`; `MailService` faengt den Transportfehler, der Controller antwortet 200: Kennwort-Zuruecksetzung kommt nie an, ohne Protokollzeile beim Start. Gemessen (Pruefung 3), beide Zustaende an drei Stellen benannt, Signal fuer `rls-preflight.mjs` (Etappe 4) benannt; NICHT in diesem Lauf behoben (kein Umbau des Transports, kein Schalter). |
+| T-GWH-05 | Information Disclosure | `favorites.service.ts` `create`, Fremdschluessel auf `WidgetInstance` | medium | mitigate | Der Unterschied zwischen "Widget gibt es nicht" (FK-Verletzung, 500) und "gehoert einem fremden Mandanten" (gelingt, weil der Fremdschluessel am Zeilenschutz vorbei prueft) ist ein Existenzorakel ueber Mandantengrenzen; dazu haengt eine fremde Zeile am Widget eines anderen (Kaskade). Pruefung 7 misst; Besitzriegel vor dem Anlegen auf dem gebundenen Klienten mit EINER Antwort (`Widget not found`) fuer alle drei Faelle; Testfaelle; Falsifizierung (b). |
+| T-GWH-06 | Denial of Service (still) / Tampering | `saveSmtpConfig` unter der ungebundenen Form | medium | mitigate | Leeres Formular nach dem Scharfschalten verleitet zum Neueintrag; das ungebundene `upsert` findet die eigene Zeile nicht und scheitert am Eindeutigkeitsindex (Pruefung 8, Konstruktor/`code` gemessen). Gebundenes `upsert` trifft die eigene Zeile (Pruefung 9); Testfall. Die Frontend-Kette bleibt als Ledger-Eintrag (Familie #28). |
+| T-GWH-07 | Server-Side Request Forgery | `icon-discovery.service.ts` | medium | accept | Nutzer-URL fuer die Icon-Suche; SSRF-Schutz (private IP-Bereiche, gesperrte Hostnamen, manuelle Weiterleitung, Zeitueberschreitung) besteht seit T-08-05 und ist in `icon-discovery.service.spec.ts` getestet; `fetchIconBytes` nimmt nur die gespeicherte URL einer eigenen Zeile (T-QFIP-01). Kein Datenbankzugriff, kein Mandantenbezug (Befund G) — unveraendert, nur gelesen. Der Besitzriegel in `create` steht VOR der Icon-Suche, damit ein fremdes Widget keinen Abruf ausloest. |
+| T-GWH-08 | Information Disclosure | `FavoriteLink`, Kollege desselben Mandanten | low | accept | Die Regel kennt keine Benutzerdimension: auf Datenbankebene sieht ein gebundener Klient die Favoriten des Kollegen (Pruefung 4, zweite Aussage). Die anwendungsseitigen `userId`-Filter bleiben; Etappe-3-Entscheidung (2). Bestehend, benannt in (f4)(a). |
+| T-GWH-09 | Repudiation / Information Disclosure | `favorites-widget.tsx`, `smtp-settings-form.tsx` | medium | accept | Die umgekehrte Fehlerrichtung ist verschluckt: `[]` wird zu `Noch keine Favoriten.`, `null` wird zu einem leeren Formular. Gemessen (Pruefungen 3/5), in (f3)/(s3) beschrieben, je ein Ledger-Eintrag (Familie #23/#25/#26/#28), Etappe-4-Vorabpruefung benannt. Das Frontend wird nicht geaendert (Umfang). |
+| T-GWH-10 | Spoofing | `favorites.controller.ts`, Mandantenquelle | low | accept | `extractContext` liest die Guard-Kennung (fuer SUPER_ADMIN umschaltbar) — dieselbe Quelle wie `dashboard`, unter dessen Bindung das referenzierte Widget liegt; eine abweichende Quelle wuerde Widget und Link trennen. Kein Mandantenfeld im DTO (gemessen). Bewusst NICHT das Claim, mit Grund in (f4)(c). |
+| T-GWH-11 | Denial of Service | `settings.service.spec.ts` -> `nodemailer` | low | mitigate | Ein echter Transport im Test liefe gegen `mailhog` (lokal nicht vorhanden: `ENOTFOUND`). `vi.mock('nodemailer')` ersetzt `createTransport`; kein Test oeffnet eine Verbindung; gegatet. |
+| T-GWH-SC | Tampering | Paketinstallation | low | accept | Dieser Plan installiert kein Paket (npm/pip/cargo) und fuegt keine Abhaengigkeit hinzu. Das Legitimitaets-Gate faellt nicht an; ausdruecklich festgehalten statt schweigend ausgelassen. |
+
+</threat_model>
+
+<verification>
+
+Nach Abschluss aller drei Aufgaben:
+
+1. `node apps/api/scripts/rls-scratch-check.mjs` meldet alle Pruefungen
+   bestanden (120 bisherige plus mindestens 8 + 9 neue, mindestens 137),
+   Rueckgabewert 0; `runFavoritesAreaChecks` und `runSettingsAreaChecks`
+   stehen nach `runAuthAreaChecks` und vor `runTransactionShapeMeasurement`.
+2. `npm --prefix apps/api run test` meldet mehr als 951 Tests gruen in
+   mindestens 62 Dateien (60 bisherige plus `favorites.service.spec.ts` und
+   `settings.service.spec.ts`).
+3. `npm --prefix apps/api run type-check` ist sauber.
+4. `npm --prefix apps/api run test -- src/prisma/rls-access-inventory.spec.ts`
+   ist gruen — `favorites.service.ts`/`favoriteLink` steht auf `gebunden`,
+   `settings.service.ts`/`smtpConfig` auf `gemischt`, die neue Fundstelle
+   `favorites.service.ts`/`widgetInstance` (falls gebaut) ist eingetragen.
+5. In `favorites.service.ts`: kein ungebundener Favoritenzugriff (auch nicht
+   in Kommentaren), sieben gebundene, fuenf Aufrufstellen des
+   Bindungshilfsmittels, ein Klient je Methode, `Widget not found`. In
+   `settings.service.ts`: genau EIN ungebundener SMTP-Zugriff (der Startpfad,
+   `findFirst()` ohne Bedingung, in `loadAnySmtpConfigForStartupTransport()`),
+   drei gebundene, kein gebundener `findFirst`; der alte Name kommt in
+   `apps/api/src` nicht mehr vor; `mail.module.ts` nennt beide Zustaende und
+   die Ledger-Nummer.
+6. `git diff --name-only 46f0e78 -- apps/api/prisma` ist leer — Schema und
+   Migrationen unangetastet; keine Compose- oder Umgebungsdatei geaendert.
+7. Alle handgepflegten Stellen der Klassifikation sind maschinell gegatet
+   und gruen; die Zaehlgates LEITEN ihre Werte aus den im Dokument genannten
+   Messanweisungen ab (Uebersichtszeilen, Summenzeile ueber alle Bereiche,
+   Paarzahl aus der Bestandsaufnahme-Tabelle).
+8. Der Umfang ist als ERLAUBNISLISTE gegatet: jede Datei, die sich
+   gegenueber `46f0e78` geaendert hat, ist eine der elf in `files_modified`
+   genannten (oder liegt unter `.planning/`). Unter `apps/api/prisma`,
+   `apps/web`, `apps/api/src/settings/settings.controller.ts`,
+   `apps/api/src/favorites/icon-discovery.service.ts`,
+   `apps/api/src/mail/mail.service.ts`, `apps/api/src/tenders`,
+   `apps/api/src/dkv` und den DTOs hat sich nichts geaendert.
+9. `.planning/WINDOWS.md`: neue offene Eintraege in Tabelle UND JSON-Block,
+   Kopfzaehler stimmen mit den Zeilen ueberein; der Platzhalter `TBD-GWH`
+   kommt nirgends mehr vor.
+10. Befund K steht an drei Stellen als ERFUELLT: (t4) Nachtrag, (d4)
+    Nachtrag, Hintergrunddienst-Abschnitt der Klassifikation.
+11. `docs/mandantentrennung-etappe2-fehlerrichtung.md` traegt
+    `## Etappe 2 — Abschluss` mit den aus den eigenen Messanweisungen
+    abgeleiteten Zahlen (Summenzeile, Paarzahl), zwischen `## Bereich
+    settings` und `## Verweis`.
+12. `DATABASE_URL` zeigt unveraendert auf die Rolle `tessera`; nichts in
+    Active Directory; kein echter SMTP-Transport in irgendeinem Test.
+
+</verification>
+
+<success_criteria>
+
+- Beide Bereiche sind gemessen, bevor gebaut wurde: zwei neue
+  Werkzeug-Abschnitte ueber den generierten Client, mit Fremdschluessel
+  (favorites) und Eindeutigkeitsindex (settings) als mitgebauten
+  Voraussetzungen der Messung.
+- Der Startpfad des Mailmoduls ist als sechster Fall der
+  Hintergrunddienst-Falle erkannt, in beiden Zustaenden gemessen, umbenannt,
+  markiert (Kopfkommentar, Modulkommentar, Klassifikation, Kritikschrift,
+  Ledger) und NICHT gebunden, NICHT umgebaut; die Unsymmetrie zu `ldap` und
+  `dkv` (Rueckfallkette, keine Protokollzeile) und die Entscheidung zum
+  eigenen Ledger-Eintrag sind mit Grund aufgeschrieben.
+- Befund K ist erfuellt und steht als erfuellt an allen drei Stellen, so dass
+  die Etappe-4-Vorabpruefung keine veraltete Bedingung fuehrt.
+- Alle Anfragewege beider Bereiche laufen ueber genau EINEN Klienten
+  `tenantPrisma` je Methode; die Besitzpruefungen bleiben; `create` prueft das
+  Widget; beide Controller-Entscheidungen zur Mandantenquelle sind begruendet
+  (dashboard-Praezedenzfall fuer favorites, ADMIN-Seite fuer settings).
+- Die umgekehrte Fehlerrichtung ist je Bereich in ihrer tatsaechlichen
+  Auspraegung benannt (`Noch keine Favoriten.`; leeres Formular ueber die
+  200-leerer-Rumpf-Kette; Speicherkonflikt gemessen) und als Ledger-Eintrag
+  je Bereich festgehalten.
+- Zwei neue Testdateien mit dem Zwei-Klienten-Nachbau, ohne echten
+  Transport; sechs Falsifizierungsnachweise (vier in Aufgabe 2, zwei an den
+  Dokument-Gates in Aufgabe 3) durchgefuehrt, zurueckgenommen, woertlich
+  notiert.
+- Etappe 2 ist vollstaendig: die fuenf handgepflegten Dokumentstellen stehen
+  auf ihrem Endstand, deriviert gegatet; die Kritikschrift hat einen
+  Abschluss-Abschnitt aus ihren eigenen Zahlen; die Anleitung widerspricht
+  dem Stand nicht mehr; Erlaubnisliste gegen `46f0e78`; Baseline gehalten
+  nach jeder Aufgabe; Schalter aus; Schema, Migrationen, Frontend, Active
+  Directory unberuehrt.
+
+</success_criteria>
+
+<output>
+Nach jeder Aufgabe committen (Praefix `feat(260911-gwh): ...` fuer Aufgabe 2,
+`docs(quick-260911-gwh): ...` fuer Aufgabe 1 und 3, wie die Vorgaenger),
+nach dem letzten Commit pushen (schlichtes `git push`, die Push-URL zeigt auf
+`localhost:3002`). Bei jedem Commit, der eine Datei loescht oder mehrere
+Pfade zugleich hinzufuegt, `git status --porcelain` VOR und NACH `git add`
+ansehen (Fehler 11 des Vorhabens). Am Ende
+`.planning/quick/260911-gwh-mandantentrennung-etappe-2-bereiche-favo/260911-gwh-SUMMARY.md`
+anlegen: tatsaechlich gezaehlte Pruefungs- und Testzahlen je Aufgabe, das
+Ergebnis von Pruefung 7 (Fremdschluessel) und Pruefung 8 (Konfliktform) mit
+Konstruktor/`code` woertlich, alle sechs Falsifizierungsnachweise mit
+Testname und Meldung woertlich, jede Abweichung von den Planungsbefunden
+ausdruecklich, die Ledger-Nummern und die Entscheidung zu #21 mit Grund, und
+ein Absatz, der den Endstand der Etappe 2 in Zahlen nennt (aus dem
+Abschluss-Abschnitt der Kritikschrift, nicht neu gerechnet). Kein naechster
+Bereichs-Lauf: Etappe 2 ist abgeschlossen; was folgt, ist Etappe 3
+(Kennzeichnung der uebergreifenden Stellen, Benutzerdimension, Anmeldeweg)
+und die Etappe-4-Vorabpruefung.
+</output>