M5: Sammelerfassung (Striche/Einzahlungen) tenant-nativ machen

stricheintragen.php und einzahlung.php lasen ihren Mitarbeiter-Picker
bisher direkt aus der global unscoped kl_Mitarbeiter-Tabelle. Fuer jeden
Mandanten ausser dem Default-Mandanten zeigte das fremde Namen und
Schreiben schlug (sicher, aber unverstaendlich) am Tenant-Check in
ledger_mirror_legacy_* fehl.

- Picker kommt jetzt aus participants (tenant-scoped), Formularfelder
  nutzen participant_id statt MitarbeiterID.
- Schreibpfad pro Teilnehmer: mit legacy_mitarbeiter_id (Default-Mandant)
  weiterhin Dual-Write nach kl_Kaffeeverbrauch/kl_Einzahlungen plus
  Ledger-Spiegelung; ohne Legacy-Verknuepfung (jeder andere Mandant) direkt
  ueber neue ledger_record_consumption()/ledger_record_payment().
- Vorderseite/Rueckseite-Filter (100-Tage-Regel) bleiben fuer den
  Default-Mandanten exakt auf der bisherigen Legacy-Logik; andere
  Mandanten nutzen die neue ledger_fetch_participants_by_window_marks()
  mit tenant_settings.sheet_window_days.
- Nebenbei behoben: einzahlung.php verlinkte auf ?aktion=... statt
  ?action=..., wodurch die Vorderseite/Rueckseite-Buttons nie griffen.
  Preis-pro-Strich-Vorbelegung kommt jetzt aus tenant_settings statt der
  seit M3 nicht mehr gepflegten kl_config-Tabelle.
- Live getestet: isolierter Test-Mandant, Picker zeigt nur eigene
  Teilnehmer, Buchungen rein Ledger-nativ mit korrektem Saldo, 10-Striche-
  Schwelle korrekt sortiert, Default-Mandant-Dual-Write weiterhin gruen.

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

docs/m5-app-kern.md

@@ -247,18 +247,60 @@ gepatcht:
   auf `kaffeeliste.php`), Zugang entzogen, anschließender Login-Versuch
   korrekt mit „kein aktiver Mandant" abgelehnt.
 
+## Fortsetzung: Sammelerfassung tenant-nativ
+
+Umgesetzte Dateien:
+
+```text
+stricheintragen.php (Picker + Schreibpfad neu)
+einzahlung.php (Picker + Schreibpfad neu)
+app/ledger.php (ledger_record_consumption, ledger_record_payment,
+  ledger_fetch_participants_by_window_marks)
+```
+
+`stricheintragen.php` und `einzahlung.php` lasen ihren Mitarbeiter-Picker
+bisher direkt aus der global unscoped `kl_Mitarbeiter`-Tabelle. Für jeden
+Mandanten außer dem Default-Mandanten war das faktisch nutzlos: Die Liste
+zeigte fremde (Default-Mandanten-)Namen an, und Schreiben schlug wegen des
+Tenant-Checks in `ledger_mirror_legacy_*` sicher, aber ohne verständliche
+Fehlermeldung fehl.
+
+- Der Picker kommt jetzt aus `ledger_fetch_participant_summaries()`
+  (tenant-scoped), Formularfelder verwenden `participant_id` statt
+  `MitarbeiterID`.
+- Beim Speichern wird pro Teilnehmer entschieden: Hat der Teilnehmer eine
+  `legacy_mitarbeiter_id` (Default-Mandant), läuft der Schreibpfad wie
+  bisher über `kl_Kaffeeverbrauch`/`kl_Einzahlungen` plus Ledger-Spiegelung.
+  Ohne Legacy-Verknüpfung (jeder andere Mandant) wird direkt über die neuen
+  Funktionen `ledger_record_consumption()`/`ledger_record_payment()` ins
+  Ledger gebucht, ohne Legacy-Tabellen zu berühren.
+- Die "Vorderseite"/"Rückseite"-Filter (100-Tage-Listen-Regel, `>= 10`
+  beziehungsweise `< 10` Striche im Fenster) bleiben für den Default-
+  Mandanten exakt auf der bisherigen Legacy-Logik (Anker: jüngstes Datum in
+  `kl_Kaffeeverbrauch`). Andere Mandanten nutzen die neue, Ledger-native
+  Fensterprüfung `ledger_fetch_participants_by_window_marks()` mit dem in
+  `tenant_settings.sheet_window_days` konfigurierten Fenster.
+- Nebenbei zwei Legacy-Bugs behoben: In `einzahlung.php` verlinkten die
+  Vorderseite/Rückseite/Alle-Buttons auf `?aktion=...`, ausgewertet wurde
+  aber `$_GET['action']` – die Filter griffen also nie. Und in beiden
+  Dateien blieb nach einem POST-Speichern `$sqlMitarbeiter` unbelegt
+  (behoben bereits in der vorherigen Session, jetzt strukturell nicht mehr
+  möglich, da die Anzeige nach dem Speichern regulär über denselben
+  Picker-Code läuft).
+- Preis-pro-Strich-Vorbelegung kommt jetzt aus `tenant_settings.mark_price_cents`
+  statt aus der mandantenunabhängigen `kl_config`-Tabelle. Das ist auch für
+  den Default-Mandanten eine Korrektur: `kl_config` wird seit M3 nicht mehr
+  über `mandant-einstellungen.php` gepflegt und kann veraltet sein.
+- Live gegen die Dev-Datenbank getestet: eigener isolierter Test-Mandant
+  angelegt, Picker zeigt nur dessen Teilnehmer, Striche und Einzahlung rein
+  Ledger-nativ gebucht (korrekter Saldo), Vorder-/Rückseiten-Schwelle bei
+  10 Strichen korrekt ein-/aussortiert, Default-Mandant weiterhin mit
+  Dual-Write geprüft. Alle Testdaten anschließend entfernt.
+
 ## Noch offen
 
 - Eigene PayPal-/Zahlungsbereich als eigenständiger App-Screen (aktuell nur im
   Dashboard integriert).
-- `stricheintragen.php` und `einzahlung.php` lesen ihre Mitarbeiter-Picker
-  weiterhin aus der global unscoped `kl_Mitarbeiter`-Tabelle. Für den
-  Default-Mandanten funktioniert das unverändert; für jeden anderen Mandanten
-  ist die Liste faktisch leer beziehungsweise zeigt (nur lesend, Schreiben
-  schlägt dank Tenant-Scope in `ledger_mirror_legacy_*` sicher fehl) die
-  Namen der Default-Mandanten-Mitglieder an. Das ist ein bestehendes,
-  eigenständiges Scope-Thema für eine spätere Iteration, keine Regression
-  dieser Session.
 - Export, Mail und Jahresprozesse bleiben M6-Themen.
 
 ## Aktueller Prüfstatus
@@ -276,3 +318,6 @@ gepatcht:
   (korrekt escaped), Soft-Delete, Banner-Anzeige auf Mandant geprüft.
 - Live-Test Zugangsvergabe/-entzug: kompletter Flow von Einladung bis
   Login-Sperre nach Entzug erfolgreich geprüft (siehe oben).
+- Live-Test Sammelerfassung für Nicht-Default-Mandanten: eigener Test-Tenant,
+  Striche/Einzahlung Ledger-nativ gebucht, Vorder-/Rückseiten-Fenster
+  geprüft (siehe oben).