Small improvements

app/EventPaymentModules/CLAUDE.md

@@ -27,13 +27,20 @@ Rechnung) liegt gekapselt in einem Modul pro Zahlungsart. Aufgelöst wird über
       Abgesichert über
       `sanitizeParticipantOptions()` / `participantOptionsComplete()` (Guard im `SignUpCommand`).
     - `type` ist i.d.R. `'string'`; `'richtext'` wird über `Views/Components/TextEditor.vue` (TinyMCE, HTML) gerendert
-      und via `v-html`/`{!! !!}` ausgegeben. Teilnehmer-Eingaben rendert die generische
-      `SignUpForm/components/PaymentMethodInputs.vue` schema-getrieben.
+      und via `v-html`/`{!! !!}` ausgegeben; `'icon'` rendert die `Views/Components/RichSelectBox.vue` (kuratierte
+      FA-Symbol-Auswahl, Liste in `resources/js/constants/paymentMethodIcons.js`). Teilnehmer-Eingaben rendert die
+      generische `SignUpForm/components/PaymentMethodInputs.vue` schema-getrieben.
+  - Optionaler Schlüssel `'hint'` je Option: erklärender Hilfetext, den die Admin-Render-Stellen unter dem Feld anzeigen
+    (z.B. bei `payment_information`, dass der Text am Anmeldeende + in der Mail erscheint).
+  - `defaultConfiguration()` je Modul liefert die Start-Config beim Anlegen der Tenant-Instanz (`CreateTenantAction`),
+    aktuell das Default-Symbol (`icon`): Überweisung `building-columns`, Sonstiges `coins`.
 - **Aktivierungs-Guard:** Eine Tenant-Zahlungsmethode darf nur `active` werden, wenn alle `required`-Optionen befüllt
   sind (`isConfigurationComplete()`), erzwungen in `UpdateAvailablePaymentMethodAction`.
 - **Config-Speicherung (JSON):** pro Tenant auf `available_payment_methods.configuration`, pro Event auf dem Pivot
   `event_payment_methods.configuration`. Beim Zuweisen an ein Event wird die Tenant-Config als **Snapshot kopiert**
-  (Copy-on-Assign, spätere Tenant-Änderungen wirken NICHT nach). Sync erfolgt differenziell in `UpdateEventCommand`.
+  (Copy-on-Assign, spätere Tenant-Änderungen wirken NICHT nach). Sync erfolgt differenziell in
+  `SetPaymentMethodsCommand` (Endpoint `/api/v1/event/details/{event}/payment-methods`, ausgelöst aus dem
+  „Teilnahmegebühren"-Bereich).
 - **`PaymentMethod` ist nur eine Fassade:** `PaymentMethod::optionsFor/participantOptionsFor/requiredOptionKeys/`
   `sanitizeConfiguration/isConfigurationComplete/defaults()` delegieren an die Registry. Bestehende Aufrufstellen
   bleiben stabil.
@@ -94,7 +101,8 @@ Beispiel GiroCode (nur Überweisung):
 ## Neues Zahlungsmodul hinzufügen
 
 1. Klasse unter `Modules/` anlegen, `extends AbstractEventPaymentModule`; `slug()`, `defaultName()`, `getOptions()`
-   implementieren; `registrationSummary()`/`doPayment()`/`createInvoice()` überschreiben, wo nötig.
+   implementieren; `defaultConfiguration()` (z.B. Default-`icon`) sowie
+   `registrationSummary()`/`doPayment()`/`createInvoice()` überschreiben, wo nötig.
 2. Zahlart-spezifische Extras als **eigenes Fähigkeits-Interface** (nicht ins Core-Interface).
 3. In `EventPaymentModuleRegistry::MODULES` eintragen. `PaymentMethod::create(['slug' => …])` wird dann automatisch über
    `ProductionDataSeeder` (iteriert `EventPaymentModuleRegistry::slugs()`) geseedet.
@@ -102,8 +110,10 @@ Beispiel GiroCode (nur Überweisung):
 
 ## Datenübernahme
 
-`storage/app/sync_payment_bank_data.php` überführt einmalig Bestands-Bankdaten (Tenant/Event) in die Modul-Config
-(idempotent). Bei Live-Inbetriebnahme einmal ausführen.
+`storage/app/2026_08_05_backfill_payment_method_configuration.sql` überführt einmalig Bestands-IBAN-Daten (Tenant/Event)
+**und** die Default-Symbole in die Modul-Config (idempotenter JSON-Merge, nichts wird überschrieben). Bei
+Live-Inbetriebnahme einmal gegen die Produktionsdatenbank ausführen — ersetzt das ältere PHP-Skript
+`sync_payment_bank_data.php`.
 
 ## Tests