M8: Mandanten-Isolation und Rollenmatrix automatisiert testen

scripts/check-m8-tenant-isolation.php: legt zwei frische, isolierte
Test-Mandanten mit je einem Teilnehmer, einer Ledger-Buchung, einem
Hinweis und einem Audit-Log-Eintrag an und prueft 10 Faelle - Lesezugriffe
(Teilnehmerlisten, Einzelabruf, letzte Buchungen, aktive Hinweise,
Audit-Log) und Schreibzugriffe (Buchung, Zugangsvergabe, Storno) sind
strikt auf den jeweils richtigen Mandanten beschraenkt. Raeumt sich selbst
auf. 10/10 gruen.

scripts/check-m8-role-matrix.php: legt einen Test-Mandanten mit je einem
Nutzer pro Rolle an (owner/admin/treasurer/member/viewer), loggt sich per
echtem HTTP-Request ein (manueller Cookie-Jar ueber file_get_contents, da
diese PHP-Installation keine curl-Extension hat) und prueft alle elf
rollen-geschuetzten Seiten gegen die erwartete Rollenliste. 55/55 gruen
(5 Rollen x 11 Seiten) - bestaetigt, dass die Rollenpruefungen ueberall
konsistent mit dem im Plan dokumentierten Rollenmodell durchgesetzt sind.

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

docs/m8-haertung.md

@@ -91,18 +91,51 @@ mailversenden.php
   eine Einstellungsänderung im UI-Protokoll mit korrektem Nutzernamen
   erscheint. Testdaten anschließend entfernt.
 
+## Mandanten-Isolation (automatisiert)
+
+Umgesetzte Datei: `scripts/check-m8-tenant-isolation.php`
+
+Legt zwei frische, isolierte Test-Mandanten mit je einem Teilnehmer, einer
+Ledger-Buchung, einem Hinweis und einem Audit-Log-Eintrag an und prüft
+10 Fälle: Teilnehmerlisten, Einzelabruf, letzte Buchungen, aktive Hinweise,
+Schreibversuche (Buchung, Zugangsvergabe, Storno) und Audit-Log sind
+strikt auf den jeweils richtigen Mandanten beschränkt; ein Zugriff über den
+falschen Mandanten liefert nichts beziehungsweise schlägt sauber fehl statt
+fremde Daten zurückzugeben. Räumt die Testdaten am Ende selbst auf.
+
+Ergebnis: grün mit 10 Assertions.
+
+## Rollenmatrix (automatisiert)
+
+Umgesetzte Datei: `scripts/check-m8-role-matrix.php`
+
+Legt einen Test-Mandanten mit je einem Nutzer pro Rolle (`owner`, `admin`,
+`treasurer`, `member`, `viewer`) an, loggt sich für jede Rolle per echtem
+HTTP-Request ein (manueller Cookie-Jar über `file_get_contents`, da diese
+PHP-Installation keine curl-Extension hat) und ruft alle rollen-geschützten
+Seiten auf: `kaffeeliste.php`, `mitarbeiterverwalten.php`, `hinweise.php`,
+`stricheintragen.php`, `einzahlung.php`, `letzteneintraege.php`,
+`csvupload.php`, `exportKaffeeliste.php`, `mailversenden.php`,
+`jahresauswertung.php`, `mandant-einstellungen.php`. Für jede
+Rolle-Seite-Kombination wird geprüft, ob der tatsächliche Zugriff (anhand
+der „Kein Zugriff"/„keine Berechtigung"-Marker in der Antwort) mit der
+erwarteten Rollenliste übereinstimmt.
+
+Ergebnis: grün mit 55 Assertions (5 Rollen × 11 Seiten). Räumt die
+Testdaten am Ende selbst auf.
+
 ## Prüfstatus
 
 - Golden Master: grün mit 104 Assertions.
 - M4 Ledger-Migration: grün mit 73 Assertions.
 - M3 Settings-Flow: grün mit 13 Assertions.
 - HTTP-Smoke: grün mit 26 geprüften Seiten.
+- M8 Mandanten-Isolation: grün mit 10 Assertions.
+- M8 Rollenmatrix: grün mit 55 Assertions.
 
 ## Noch offen in M8
 
 - Content-Security-Policy (braucht Template-Bereinigung der Inline-Styles).
-- Mandanten-Isolation automatisiert testen.
-- Rollenmatrix automatisiert testen.
 - Datenexport pro Mandant.
 - Lösch-/Anonymisierungsprozess für Teilnehmer und Kunden.
 - Backup-/Restore-Prozess und Monitoring/Fehlerlogging dokumentieren.