M5 abschliessen: Schreibseiten aufs Ledger umstellen, Storno statt Delete

- stricheintragen.php und einzahlung.php erhielten bisher gar keine
  Zugriffskontrolle (nur CSRF), jetzt Rollen-/Legacy-Fallback wie in
  kaffeeliste.php; Sammeleintraege spiegeln transaktional ins Ledger
  (ledger_mirror_legacy_payment neu ergaenzt).
- letzteneintraege.php war rein ueber Legacy-Admin gesperrt und haette
  neue SaaS-Mandanten ausgeschlossen; Loeschen markiert den gespiegelten
  Ledger-Eintrag jetzt per voided_at statt ihn zu entfernen
  (ledger_void_entry_by_legacy_id).
- check-m4-ledger-migration.php an das Storno-Modell angepasst: verwaiste
  Ledger-Zeilen sind nur noch ein Fehler, wenn sie nicht voided sind.
- Nebenbei: PHP-Warning bei Sammelerfassung behoben, toten Code entfernt,
  veraltete README (verwies auf nicht existierende saas-app/-Struktur)
  korrigiert.

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

docs/m5-app-kern.md

@@ -1,6 +1,6 @@
 # M5 App-Kern
 
-Stand: 2026-07-14
+Stand: 2026-07-14 (fortgeführt)
 
 M5 stellt die operativen App-Seiten schrittweise auf das neue tenant-sichere
 Modell um. Der Start erfolgt bewusst read-only, damit Summen, Links und
@@ -67,15 +67,80 @@ Umgesetzter Umfang `index.php`:
 - Eigene Web-Striche bleiben mit dem bestehenden Legacy-Datensatz kompatibel
   und werden direkt ins Ledger gespiegelt.
 
+## Fortsetzung: Schreibseiten und Storno
+
+Umgesetzte Dateien:
+
+```text
+stricheintragen.php
+einzahlung.php
+letzteneintraege.php
+app/ledger.php
+scripts/check-m4-ledger-migration.php
+```
+
+Umgesetzter Umfang `stricheintragen.php` und `einzahlung.php`:
+
+- Beide Sammelerfassungsseiten waren zuvor ohne jede Zugriffsprüfung
+  erreichbar (nur CSRF-Schutz, kein `checkKaffeelisteAdmin`- oder Rollen-Check).
+  Das ist jetzt behoben: Zugriff erfordert SaaS-Rolle `owner`, `admin` oder
+  `treasurer`, oder im Legacy-/Dev-Fallback `checkKaffeelisteAdmin` mit dem
+  Default-Tenant.
+- Jede eingetragene Legacy-Zeile (`kl_Kaffeeverbrauch` beziehungsweise
+  `kl_Einzahlungen`) wird innerhalb derselben Transaktion sofort über
+  `ledger_mirror_legacy_consumption()` beziehungsweise die neue
+  `ledger_mirror_legacy_payment()` ins Ledger gespiegelt. Schlägt die
+  Spiegelung fehl, wird die gesamte Sammelerfassung zurückgerollt statt
+  teilweise gespeichert zu werden.
+- Ein vorbestehender Bug wurde nebenbei behoben: Bei einer POST-Anfrage blieb
+  `$sqlMitarbeiter` unbelegt, was einen PHP-Warning erzeugte und die
+  Mitarbeiterliste nach dem Speichern leer ließ.
+
+Umgesetzter Umfang `letzteneintraege.php`:
+
+- Der Seitenzugriff nutzte bisher ausschließlich den Legacy-Check
+  `checkKaffeelisteAdmin`, wodurch neu registrierte SaaS-Mandanten (ohne
+  Legacy-`kl_Mitarbeiter`-Zeile) die Seite nie hätten nutzen können. Jetzt gilt
+  dieselbe Rollen-/Fallback-Logik wie in `kaffeeliste.php`.
+- Löschen erzeugt keinen harten Delete im Ledger mehr. Neue Funktion
+  `ledger_void_entry_by_legacy_id()` setzt `voided_at` auf dem gespiegelten
+  Ledger-Eintrag, bevor die Legacy-Zeile aus `kl_Einzahlungen` oder
+  `kl_Kaffeeverbrauch` entfernt wird (in einer Transaktion). Der Ledger-Eintrag
+  bleibt damit für die Revision erhalten; alle Lesepfade filtern bereits
+  konsistent auf `voided_at IS NULL`.
+- Zwei nie aufgerufene Funktionen (`berechneGesamtausgabe`,
+  `berechneGesamtstriche`, `berechneGesamteinzahlungen`) wurden als toten Code
+  entfernt.
+
+Angepasstes Check-Skript:
+
+- `scripts/check-m4-ledger-migration.php` ging bisher davon aus, dass jeder
+  gespiegelte Ledger-Eintrag eine noch existierende Legacy-Zeile hat. Das ist
+  durch das Storno-Modell nicht mehr korrekt: Ein stornierter Eintrag hat
+  absichtlich keine Legacy-Zeile mehr, bleibt aber im Ledger stehen. Die
+  Prüfungen filtern jetzt zusätzlich auf `voided_at IS NULL`, sodass echte
+  Dateninkonsistenzen weiterhin erkannt werden, stornierte Einträge aber nicht
+  mehr als Fehler zählen.
+
+Alle drei Flows wurden gegen die Remote-Dev-Datenbank live per HTTP getestet
+(Sammeleintrag Striche, Sammeleinzahlung, Storno beider Buchungsarten über
+`letzteneintraege.php`) und anschließend wieder auf den Ausgangsstand
+zurückgesetzt.
+
 ## Noch offen
 
-- Schreibseiten `stricheintragen.php` und `einzahlung.php` erst danach mit
-  Storno-/Reversal-Strategie vorbereiten.
+- Eigene PayPal-/Zahlungsbereich als eigenständiger App-Screen (aktuell nur im
+  Dashboard integriert).
+- Mitgliederverwaltung tenant- und rollenbasiert umsetzen
+  (`mitarbeiterverwalten.php` ist noch nicht angefasst).
+- Hinweise als tenant-spezifische Notices umsetzen.
 - Export, Mail und Jahresprozesse bleiben M6-Themen.
 
 ## Aktueller Prüfstatus
 
-- M4 Ledger-Migration: grün mit 73 Assertions.
+- M4 Ledger-Migration: grün mit 73 Assertions (Storno-fähig).
 - M4 Ledger-Service: grün mit 115 Assertions.
 - Golden Master: grün mit 104 Assertions.
 - HTTP-Smoke: grün mit 23 geprüften Seiten.
+- Live-Test der Schreibflows gegen die Dev-DB: Sammelstriche, Sammeleinzahlung
+  und Storno beider Buchungsarten erfolgreich geprüft.