M6: CSV-Import mit Vorschau, Dublettenpruefung und Audit-Trail

csvupload.php verarbeitete CSV-Zeilen bisher sofort beim Upload, ohne
Vorschau, ohne Zugriffskontrolle (nur CSRF) und schrieb ausschliesslich in
die global unscoped kl_Einzahlungen-Tabelle.

- Neue Tabellen payment_import_batches/payment_import_rows protokollieren
  jeden Import: Datei, Pruefsumme, jede Zeile mit Rohwerten, erkanntem
  Mitglied, Status und erzeugter Ledger-Zeile.
- Zweistufiger Ablauf: Hochladen zeigt nur eine Vorschau (matched/
  duplicate/unmatched/invalid), erst "Import bestaetigen" bucht.
- Zuordnung per paypal_name oder display_name (tenant-scoped), Dubletten-
  pruefung gegen bestehende nicht-stornierte Ledger-Zahlungen.
- Buchung folgt dem etablierten Zweig-Muster: Default-Mandant per
  Dual-Write nach kl_Einzahlungen plus Spiegelung, alle anderen Mandanten
  direkt ueber ledger_record_payment().
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback).
- Live getestet: Treffer, unbekannter Name, ungueltiger Betrag korrekt
  klassifiziert; Import bestaetigt mit korrektem Dual-Write; erneuter
  Upload derselben Datei erkennt die Zeile korrekt als Dublette.

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

docs/m6-import-export-mail.md

@@ -0,0 +1,60 @@
+# M6 Import, Export und Mail
+
+Stand: 2026-07-15
+
+M6 macht die Admin-/Treasurer-Flows produktionsreif: CSV-Import,
+PDF-/Listenexport, Mailversand und Jahresprozesse laufen tenant-sicher
+gegen das neue Modell statt gegen Legacy-Tabellen direkt.
+
+## CSV-Import
+
+Umgesetzte Dateien:
+
+```text
+database/migrations/0008_saas_payment_imports.sql
+app/imports.php
+csvupload.php
+```
+
+Ziel: Zahlungsimport mit echter Vorschau, Dublettenprüfung und Audit-Trail,
+statt sofortiger Verarbeitung ohne Bestätigungsschritt wie im Legacy-Stand.
+
+Umfang:
+
+- Neue Tabellen `payment_import_batches` und `payment_import_rows` (siehe
+  Kernschema im Umstrukturierungsplan) protokollieren jeden Import: Datei,
+  Prüfsumme, Zeitpunkt, jede einzelne Zeile mit Rohwerten, erkanntem
+  Mitglied, Status und – nach Bestätigung – der erzeugten Ledger-Zeile.
+- Zweistufiger Ablauf: Hochladen erzeugt eine Vorschau (`status = previewed`)
+  ohne jede Buchung; erst der zweite Schritt „Import bestätigen“ committet
+  die als `matched` erkannten Zeilen (`status = committed`).
+- Zeilen werden klassifiziert: `matched` (wird gebucht), `duplicate`
+  (gleicher Teilnehmer, gleicher Betrag, gleicher Tag existiert bereits als
+  nicht-stornierte Ledger-Zahlung), `unmatched` (kein Mitglied per
+  `paypal_name` oder `display_name` gefunden), `invalid` (Betrag oder Datum
+  nicht parsebar).
+- Zuordnungsregel entspricht der Legacy-Logik: Name aus der CSV wird gegen
+  `paypal_name` oder `display_name` verglichen (case-insensitiv).
+- Buchung folgt demselben Zweig-Muster wie die übrige Sammelerfassung: Für
+  Teilnehmer mit `legacy_mitarbeiter_id` (Default-Mandant) wird zusätzlich
+  eine `kl_Einzahlungen`-Zeile geschrieben und gespiegelt; alle anderen
+  Mandanten werden direkt über `ledger_record_payment()` gebucht.
+- Zugriffskontrolle ergänzt: Die Seite hatte zuvor gar keine Prüfung außer
+  CSRF. Jetzt gilt dieselbe Rollen-/Legacy-Fallback-Logik wie bei
+  `einzahlung.php` (`owner`, `admin`, `treasurer`).
+- Upload-Härtung aus M2 (Größen-/Typprüfung, Speicherung außerhalb des
+  direkt erreichbaren Codes unter `var/uploads`, Löschung nach Verarbeitung)
+  bleibt erhalten.
+
+Live gegen die Dev-Datenbank getestet: Upload mit drei Testzeilen (Treffer,
+unbekannter Name, ungültiger Betrag), Vorschau-Klassifizierung geprüft,
+Import bestätigt (Dual-Write und Ledger-Spiegelung korrekt), erneuter Upload
+derselben Datei erkennt die bereits importierte Zeile korrekt als Dublette.
+Testdaten anschließend entfernt.
+
+## Prüfstatus
+
+- Golden Master: grün mit 104 Assertions.
+- M4 Ledger-Migration: grün mit 73 Assertions.
+- M4 Ledger-Service: grün mit 115 Assertions.
+- HTTP-Smoke: grün mit 23 geprüften Seiten.