feat: Enhance club payment claims and task automation

- Added `paid_amount_cents` column to `club_payment_claims` for better tracking of payments.
- Implemented compatibility checks for the new column in `clubPaymentClaimService` and `clubTaskAutomationService`.
- Updated various views to handle read-only states when editing is not allowed.
- Refactored forms in `ClubAccountsView`, `ClubInvoicesView`, `ClubTasksView`, and `ClubCommunicationView` to use factory functions for cleaner code.
- Introduced a new migration script to add the `paid_amount_cents` column if it doesn't exist and initialize it for existing paid claims.
- Created a detailed plan for enhancing club features and ensuring stability in existing modules.

docs/TODO.md

@@ -56,6 +56,7 @@ Stand: 2026-06-22
 - [ ] Historie feiner filtern, exportieren und moduluebergreifend verlinken.
 - [ ] Kommunikation um Dokumentanhaenge und Serienvorlagen erweitern.
 - [ ] Vereinsarchiv um weitere Entitaeten und komfortablere Suche erweitern.
+- Detailplan fuer Club-Ausbau und Absicherung: [club-outstanding-plan.md](./club-outstanding-plan.md).
 - [ ] Die alte Optimierungs-Restliste bei Bedarf mit [OPTIMIZATION_TODO.md](./OPTIMIZATION_TODO.md) zusammenfuehren.
 
 ## Fehlend

docs/club-outstanding-plan.md

@@ -0,0 +1,129 @@
+# Club-Produkt: Ausbau und Absicherung
+
+Stand: 2026-06-25
+
+## Ziel
+
+Die vorhandenen Club-Module sollen nicht mehr nur "vorhanden", sondern im Alltag stabil und nachvollziehbar nutzbar sein. Der Schwerpunkt liegt jetzt auf zwei Dingen:
+
+- Ausbau der noch klar erkennbaren Restthemen.
+- Absicherung der bereits fertig wirkenden Arbeitsbereiche gegen Kantenfaelle, Rechteprobleme und unklare Zustande.
+
+## Aktueller Fokus
+
+- Kommunikation
+- Historie
+- Archiv
+- Restliche Club-UI-Absicherung in den Kernviews
+- Danach erst das `mein-tt.de`-Produkt inhaltlich weiter ausbauen
+
+## Arbeitsreihenfolge
+
+### Phase 1: Absicherung der bestehenden Club-Views
+
+Status: in Arbeit
+
+Ziel:
+- Keine haengenden Formulare bei Reload, Clubwechsel oder Auswahlwechsel.
+- Read-only-Zustaende sind sichtbar und verhindern keine Navigation.
+- Lade- und Fehlermeldungen sind konsistent und eindeutig.
+
+Konkrete Teilaufgaben:
+- `ClubTasksView.vue`: Sicherstellen, dass `selectedTask` und `form` beim Clubwechsel, bei leerer Liste und nach Loesch-/Archivaktionen sauber getrennt werden.
+- `ClubCommunicationView.vue`: `selectedThread`, `threadForm`, `groupForm`, `templateForm` und `messageForm` beim Clubwechsel und nach Auswahlwechseln komplett zuruecksetzen.
+- `ClubAccountsView.vue`: `selectedAccount`, `selectedTransaction`, `form` und `transactionForm` in jedem Ruecksprung sauber bereinigen.
+- `ClubInvoicesView.vue`: `selectedInvoice`, `selectedParty`, `invoiceForm` und `partyForm` beim Clubwechsel und bei leeren Selektionen auf Default bringen.
+- Read-only-Hinweise auf jeder der vier Views vereinheitlichen, damit ein Nutzer mit fehlenden Rechten nicht erst in die Formulare klickt, um zu merken, dass keine Bearbeitung moeglich ist.
+- Ladezustände und Fehlerbanner auf eine einheitliche Form bringen, damit Reload und Fehlerfall nicht unterschiedlich wirken.
+- Ein kurzer Smoke-Check je View nach der Aenderung: Liste laden, Element auswaehlen, Auswahl loeschen, Club wechseln, erneut laden.
+
+Gepruefte Kantenfaelle:
+- Club wird gewechselt, waehrend ein Detailformular offen ist.
+- Datenquelle liefert eine leere Liste und der zuletzt selektierte Datensatz existiert nicht mehr.
+- Nutzer hat nur Leserechte, soll aber trotzdem eine klare Orientierung haben.
+- Reload erfolgt waehrend ein Formular bereits mit Daten befuellt ist.
+
+Fertig, wenn:
+- Die vier Kernviews ohne manuelle Nacharbeit zwischen Liste, Detail und Neu-Anlage wechseln.
+- Beim Clubwechsel keine Formularwerte aus dem vorherigen Club sichtbar bleiben.
+- Read-only-Nutzer die Bereiche verstehen, ohne in kaputte Aktionen zu laufen.
+
+### Phase 2: Kommunikation produktiv absichern
+
+Ziel:
+- Nachrichtenfluss nicht nur funktional, sondern praxisnah robust machen.
+
+Arbeitspakete:
+- SMTP real testen, inklusive Zustellprotokoll und Fehlerfaelle.
+- Optional Reply-To pro Verein oder Kommunikationsvorlage sauber ergaenzen.
+- Dokumentanhaenge fuer Nachrichten und Vorlagen einfuehren.
+- Serienvorlagen und wiederkehrende Nachrichtentypen vorbereiten.
+
+Fertig, wenn:
+- Eine Testzustellung je Verein reproduzierbar gelingt.
+- Fehlende SMTP-Konfiguration klar und frueh sichtbar wird.
+- Nachrichten mit Anhaengen und Vorlagen ohne Sonderlogik im Alltag einsetzbar sind.
+
+### Phase 3: Historie und Archiv vertiefen
+
+Ziel:
+- Vergaengliche Vorgange muessen spaeter besser auffindbar und nachvollziehbar sein.
+
+Arbeitspakete:
+- Historie nach Modulen und Vorgangstypen filtern.
+- Historie exportierbar machen.
+- Historie mit Zielobjekten und Querverweisen versehen.
+- Archiv um weitere Entitaeten erweitern.
+- Archivsuche und Schnellfilter verbessern.
+
+Fertig, wenn:
+- Vorstand oder Verwaltung einen Vorgang aus Historie oder Archiv ohne Umweg wiederfinden kann.
+- Wichtige Clubobjekte nicht nur archiviert, sondern auch wieder auffindbar und verlinkt sind.
+
+### Phase 4: Restliche Club-UX verdichten
+
+Ziel:
+- Das Dashboard und die Detailmodule sollen gleiche Sprache sprechen.
+
+Arbeitspakete:
+- Dashboard-Schnellzugriffe weiter auf Tagesgeschaeft trimmen.
+- Verlinkungen zwischen Dashboard, Mitgliedern, Zahlungen, Kommunikation und Archiv schaerfen.
+- Kleine Inkonsistenzen in Statusworten, Akzentfarben und Listenlabels bereinigen.
+
+Fertig, wenn:
+- Der Einstieg immer zur naechsten sinnvollen Aktion fuehrt.
+- Die wichtigsten Statuswerte nicht doppelt oder widerspruechlich gezeigt werden.
+
+### Phase 5: Player-Produkt erst danach
+
+Ziel:
+- `mein-tt.de` bekommt nur dann neue Inhalte, wenn die Club-Seite stabil ist.
+
+Arbeitspakete:
+- Anforderungen fuer Spieleransichten separat sammeln.
+- Keine Club-spezifischen Workflows mehr in das Player-Produkt ziehen.
+- Neue Spielerfeatures nur gegen eigene Prioritaeten und nicht als Restverwertung der Club-Roadmap planen.
+
+## Nicht als naechstes anfassen
+
+- Generelles Beitrags- und Tarifsystem mit Familienlogik, Alterslogik und Gueltigkeitszeitrainen.
+- Weitere grosse Produktumbauten ohne klaren Nutzen fuer den Club-Alltag.
+- Zusätzliche Club-Module, solange die bestehenden Workflows noch nicht absicherungsfest sind.
+
+## Konkrete naechste Tickets
+
+- SMTP-Test fuer Kommunikation mit realer Zieladresse und dokumentiertem Ergebnis.
+- Dokumentanhaenge fuer Kommunikation und Vorlagen.
+- Historie: Filter und Export.
+- Archiv: weitere Objektklassen und Suche.
+- Club-UI-Smoke-Check fuer Aufgaben, Kommunikation, Konten und Rechnungen.
+
+## Abhaengigkeiten
+
+- SMTP-Test braucht eine real erreichbare Versandkonfiguration.
+- Historie-Export braucht klare Zielobjekt- und Filterdefinitionen.
+- Archiv-Erweiterungen sollten auf bereits vorhandene Dokument-, Rechnungs- und Beitragsdaten aufsetzen.
+
+## Erwartetes Ergebnis
+
+Nach dieser Runde sind die Club-Bereiche nicht nur vorhanden, sondern im Alltag kontrollierbar, nachvollziehbar und ausreichend robust fuer den produktiven Einsatz eines Vereins. Danach kann der Fokus auf neue inhaltliche Produktarbeit wechseln.