M5: Hinweise auf tenant-scoped Notices umziehen, Mitgliederzugang auf Rollen umstellen

Hinweise:
- Neue Tabelle notices (tenant-scoped, Soft-Delete via deleted_at) loest
  die global unscoped kl_hinweise als aktive Datenquelle ab; Migration
  uebernimmt einmalig aktuell gueltige kl_hinweise-Eintraege fuer den
  Default-Mandanten. kl_hinweise bleibt als Golden-Master-Referenz stehen.
- hinweise.php und der Banner in header.php sind tenant-scoped umgestellt.

Mitgliederverwaltung:
- mitarbeiterverwalten.php verwaltet jetzt participants (tenant-scoped)
  statt der global unscoped kl_Mitarbeiter-Tabelle als primaere Quelle.
  Das behebt nebenbei ein Mandanten-Datenleck: jeder SaaS-Mandant mit
  Owner/Admin-Rolle haette zuvor die komplette Default-Mandanten-
  Mitgliederliste sehen und bearbeiten koennen.
- Fuer den Default-Mandanten bleibt Dual-Write nach kl_Mitarbeiter
  bestehen, damit stricheintragen.php/einzahlung.php weiter funktionieren;
  andere Mandanten werden rein participant-nativ verwaltet.
- Die Legacy-Administrator-Checkbox ist raus. Stattdessen kann ein Admin
  je Mitglied unabhaengig von Name/E-Mail einen Login-Zugang mit Rolle
  (member/treasurer/admin) gewaehren oder entziehen
  (saas_grant_participant_access / saas_revoke_participant_access).
  Einladung laeuft ueber den bestehenden Passwort-Reset-Mechanismus,
  Entzug setzt die Mitgliedschaft auf revoked statt sie zu loeschen.
- Kompletter Flow live getestet: anlegen, Zugang gewaehren, Einladungsmail,
  Passwort setzen, Login, Rollenschutz, Zugang entziehen, Login-Sperre.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/saas-umstrukturierungsplan.md

@@ -305,7 +305,7 @@ Nicht tun:
 | M2 | Technisches Fundament | Abgeschlossen: Migrationen, Bootstrap, Session, CSRF-Helper und Legacy-Schreibseitenschutz stehen |
 | M3 | SaaS-Basis | Abgeschlossen: Tenants, User, Registrierung, Login, Rollen, Mail-Links und zentrale Mandantenauswahl funktionieren |
 | M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritätscheck, Ledger-Service und Preview sind umgesetzt |
-| M5 | App-Kern | Weit fortgeschritten: Kernseiten lesen und schreiben tenant-sicher gegen das Ledger; offen sind Hinweise und ein eigener Zahlungs-Screen |
+| M5 | App-Kern | Weit fortgeschritten: Kernseiten lesen und schreiben tenant-sicher gegen das Ledger, inklusive Hinweise und rollenbasiertem Zugang; offen ist ein eigener Zahlungs-Screen |
 | M6 | Betriebsflows | Import, Export, Mail und Jahresprozesse sind auditierbar |
 | M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spätere Ausbaustufen folgen |
 | M8 | Härtung | Betrieb, Datenschutz, Monitoring und Isolation sind geprüft |
@@ -515,9 +515,15 @@ Schritte:
   `index.php`. Ein eigener `/app/einzahlungen`-Screen wie ursprünglich in der
   Zielarchitektur skizziert existiert nicht separat; die Funktion ist bewusst
   im Dashboard gebündelt statt als eigene Route.
-- Mitgliederverwaltung tenant- und rollenbasiert umsetzen: erledigt in
-  `mitarbeiterverwalten.php`, inklusive Spiegelung nach `participants` und
-  Behebung einer gespeicherten XSS-Lücke bei Name/E-Mail.
+- Mitgliederverwaltung tenant- und rollenbasiert umsetzen: erledigt.
+  `mitarbeiterverwalten.php` verwaltet jetzt `participants` als primäre,
+  tenant-scoped Quelle (nicht mehr die global unscoped `kl_Mitarbeiter`-
+  Tabelle) und erlaubt Admins, Mitgliedern unabhängig von Name/E-Mail einen
+  Login-Zugang mit Rolle zu gewähren oder zu entziehen (Einladung per Mail
+  über den bestehenden Passwort-Reset-Mechanismus, Entzug als Statuswechsel
+  statt Delete). Nebenbei behoben: eine gespeicherte XSS-Lücke bei Name/
+  E-Mail und ein Mandanten-Datenleck, weil die alte Version jedem
+  SaaS-Mandanten die komplette Default-Mandanten-Mitgliederliste zeigte.
 - Gesamtübersicht umsetzen: erster read-only Stand in `kaffeeliste.php`
   erledigt.
 - Teilnehmerauswertung umsetzen: read-only Stand in `teilnehmerauswertung.php`
@@ -529,8 +535,10 @@ Schritte:
 - Sammelerfassung (`stricheintragen.php`, `einzahlung.php`) tenant-sicher
   absichern und ans Ledger anbinden: erledigt. Beide Seiten hatten zuvor
   keine Zugriffskontrolle außer CSRF; das ist behoben.
-- Hinweise als tenant-spezifische Notices umsetzen: offen, `hinweise.php`
-  ist noch vollständig Legacy ohne Tenant-Bezug.
+- Hinweise als tenant-spezifische Notices umsetzen: erledigt. Neue Tabelle
+  `notices` mit Soft-Delete, `hinweise.php` und die Banner-Anzeige in
+  `header.php` sind tenant-scoped umgestellt; `kl_hinweise` bleibt nur noch
+  als Golden-Master-Referenz bestehen.
 
 Ergebnis:
 
@@ -717,7 +725,9 @@ UX-Prüfungen:
   werden?
 - Wie sollen Kunden-Tenants adressiert werden: Subdomain, Pfad oder Auswahl nach
   Login?
-- Welche Rolle soll `treasurer` haben: eigene Rolle oder Teil von `admin`?
+- ~~Welche Rolle soll `treasurer` haben: eigene Rolle oder Teil von `admin`?~~
+  Entschieden mit der M5-Zugangsvergabe: `treasurer` ist eine eigene,
+  über `mitarbeiterverwalten.php` vergebbare Rolle, getrennt von `admin`.
 - Wird das Umfrage-Modul Teil des SaaS-Produkts oder nur archiviert?
 - Braucht der MVP schon Tarife/Billing oder erstmal nur Registrierung?
 - Sollen bestehende Kunden per Einladung oder per Self-Service onboarden?