docs: zwei Produktentscheidungen des Users fuer Etappe 3 festgehalten

.planning/STATE.md

@@ -424,6 +424,6 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 Last session: 2026-09-10T12:35:40.000Z
 Resumed: 2026-09-09 — Sitzung ueber /gsd-resume-work fortgesetzt; Einstiegspunkt Etappe 2 (Bereich ldap), Auswahl des Nutzers steht aus.
-Stopped at: Quick 260910-jab abgeschlossen — die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) sind geschlossen, VORGEZOGEN auf ausdruecklichen Nutzerwunsch vor die restlichen fuenf offenen Bereiche der Etappe 2 (dashboard 13, calendar 12, tenant 8, favorites 7, auth 5, settings 4 — sechs, nicht fuenf, `settings` war bereits vorher als Reihenfolgebedingung fuer Etappe 4 markiert, Befund K). Diese fuenf/sechs Bereiche messen ab jetzt gegen die NEUEN Regeln aus 20260910120000_rls_widen_membership_grant_and_platform_read. WINDOWS #19 fixed, WINDOWS #24 neu offen (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle). Naechster Schritt laut vorheriger Uebergabe: Bereich dashboard (13 Zugriffe), danach wie zuvor geplant. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten.
+Stopped at: Quick 260910-jab abgeschlossen — die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) sind geschlossen, VORGEZOGEN auf ausdruecklichen Nutzerwunsch vor die restlichen fuenf offenen Bereiche der Etappe 2 (dashboard 13, calendar 12, tenant 8, favorites 7, auth 5, settings 4 — sechs, nicht fuenf, `settings` war bereits vorher als Reihenfolgebedingung fuer Etappe 4 markiert, Befund K). Diese fuenf/sechs Bereiche messen ab jetzt gegen die NEUEN Regeln aus 20260910120000_rls_widen_membership_grant_and_platform_read. WINDOWS #19 fixed, WINDOWS #24 neu offen (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle). Naechster Schritt laut vorheriger Uebergabe: Bereich dashboard (13 Zugriffe), danach wie zuvor geplant. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten. ZWEI PRODUKTENTSCHEIDUNGEN DES USERS VOM 2026-09-10, beide fuer Etappe 3 (nach Abschluss von Etappe 2): (1) ANMELDENAMEN PRO MANDANT EINDEUTIG, nicht plattformweit — m.schmidt darf es bei Firma A und Firma B geben. Folge: `User.username`/`User.email` von `@unique` auf `@@unique([tenantId, username])`/`@@unique([tenantId, email])` umstellen, und der Anmeldeweg muss den Mandanten kennen, BEVOR er die Benutzerzeile sucht (heute kommt der Mandant erst AUS der Zeile; die drei SECURITY-DEFINER-Funktionen aus Etappe 1 suchen ueber den Namen allein). Ueblicher Weg: eigene Adresse je Mandant (Subdomain) oder Mandantenwahl beim Login. Loest zugleich den bewusst ungebundenen `resolveEmailForWrite`-Pfad (ldap) und die Kollisionskette unsichtbar->frei->P2002 (tenders, user). (2) KOLLEGEN DERSELBEN FIRMA STRIKT GETRENNT — jeder sieht nur seine eigenen gespeicherten Suchen, Favoriten, Dashboard-Anordnung. Heute trennt das nur der Anwendungscode; alle Regeln lesen `tenantId = current_tenant_id()` ohne Benutzerdimension. Folge: zweite Sitzungsvariable `app.current_user` samt `current_user_id()`, an jeder Bindungsstelle mitgesetzt, und Benutzerdimension in den Regeln der nutzerbezogenen Tabellen (TenderSavedSearch, TenderTriage, TenderNotificationPref, TenderEmailConfig, TenderRssFeedSource persoenliche Zeilen, DashboardLayout, WidgetInstance, SearchProvider, FavoriteLink, CalendarSource). Danach faengt die Datenbank auch einen Programmierfehler ab, der heute unbemerkt bliebe. Beides eigene Umbauten; Reihenfolge: erst Etappe 2 zu Ende, dann diese beiden als Etappe 3, dann Scharfschalten.
 Resume file: None
 Last activity: 2026-09-10 - Completed quick task 260910-jab: Die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) geschlossen