M6: Jahresabschluss als generisches Feature statt AOK-spezifischem Bonus-Skript

jahresauswertung.php verband sich bisher mit fest codierten (kaputten)
Zugangsdaten selbst zur Datenbank statt ueber config.php, hatte keine
Zugriffskontrolle und kein CSRF, und verteilte bei jedem Aufruf sofort
einen hart codierten Bonus-Topf (490 Striche a 0,20 Euro) per PHPMailer
(dessen Quelldateien im Repo fehlen) mit AOK-spezifischem Mailtext.

Nach Abstimmung mit dem Kunden als generisches, mandantenfaehiges Feature
neu gebaut statt nur deaktiviert oder rein lesend umgesetzt:

- Admin gibt einen frei waehlbaren Gesamtbetrag ein, das System verteilt
  ihn proportional zu den Jahresstrichen auf alle aktiven Mitglieder.
- Standardmaessig aktive Dry-Run-Checkbox zeigt die Verteilung, ohne zu
  buchen oder Mails zu verschicken.
- Bestaetigter Lauf bucht ueber dasselbe Zweig-Muster wie ueberall
  (Default-Mandant Dual-Write, andere Mandanten ledger_record_payment)
  und verschickt personalisierte Mails ueber saas_send_mail(), protokolliert
  im outbound_emails-Versandlog.
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback).
- http-smoke.php: jahresauswertung.php jetzt regulaerer Check statt
  uebersprungenem unsicherem Aufruf; damit sind keine Seiten mehr
  uebersprungen oder als bekannter offener Punkt markiert (26/26 gruen).

Live getestet: Dry-Run mit korrekter proportionaler Verteilung (Summe
ergibt exakt den Gesamtbetrag), Live-Lauf bucht und versendet korrekt,
Testdaten anschliessend vollstaendig entfernt.

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

docs/saas-umstrukturierungsplan.md

@@ -306,7 +306,7 @@ Nicht tun:
 | 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, inklusive Hinweise und rollenbasiertem Zugang; offen ist ein eigener Zahlungs-Screen |
-| M6 | Betriebsflows | Weit fortgeschritten: CSV-Import, PDF-Export und Mailversand stehen; Jahresprozesse offen |
+| M6 | Betriebsflows | Abgeschlossen: Import, Export, Mail und Jahresabschluss 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 |
 | M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only |
@@ -585,13 +585,21 @@ Schritte:
   PayPal-Link, FAQ-URL). Ersetzt durch die bestehende `saas_send_mail()`-
   Abstraktion aus M3, eine neue `outbound_emails`-Tabelle als Versandlog
   und eine standardmäßig aktive Dry-Run-Option.
-- Jahresauswertung beziehungsweise Jahresbuchungen tenant-sicher abbilden.
+- Jahresauswertung beziehungsweise Jahresbuchungen tenant-sicher abbilden:
+  erledigt. Die ursprüngliche Seite verband sich mit fest codierten,
+  kaputten Zugangsdaten selbst zur Datenbank (an `config.php` vorbei),
+  hatte keine Zugriffskontrolle und verteilte bei jedem Aufruf sofort einen
+  hart codierten Bonus-Topf mit AOK-spezifischem Mailtext. Nach Abstimmung
+  mit dem Kunden als generisches Feature umgesetzt: frei wählbarer
+  Gesamtbetrag, proportionale Verteilung nach Jahresstrichen, Dry-Run,
+  Buchung und Mailversand mit Protokoll.
 
 Ergebnis:
 
 - Kassenverwaltung ist für reale Betriebsabläufe vollständig.
 - Import/Export/Mail sind auditierbar.
-- Stand: gestartet. Dokumentation: `docs/m6-import-export-mail.md`.
+- Stand: abgeschlossen für den M6-Scope. Dokumentation:
+  `docs/m6-import-export-mail.md`.
 
 Abhängigkeiten: