Wiederkehrende Zahlungen aufspueren

Am Anfang einer Betreuung weiss niemand, welche Vertraege es gibt. Die
Antwort steht aber im Kontoauszug: Wer regelmaessig abbucht, hat einen
Vertrag. Neu unter Vermoegen & Kasse wird aus hunderten Buchungszeilen
eine Arbeitsliste.

Aufbau:
- Die Erkennung liegt als reine Funktionen in
  src/lib/finanzen/wiederkehrend.ts, ohne Datenbank. Nur so laesst sich
  jede Einordnung einzeln nachrechnen.
- Der Datenzugriff steht getrennt in wiederkehrend-laden.ts.
- Ein kleines Modell haelt fest, was bewusst KEIN Vertrag ist. Es haengt
  am normalisierten Empfaengernamen, nicht an Buchungen - nur so
  ueberlebt die Entscheidung den naechsten Import.

Zwei Haltungen liegen der Erkennung zugrunde:

Im Zweifel getrennt lassen. Zusammengefasst wird nur das Unstrittige:
Gross- und Kleinschreibung, Satzzeichen, Umlaute, Rechtsform am Ende.
Keine Aehnlichkeitssuche - "Stadtwerke Bamberg" und "Stadtwerke
Bayreuth" trennen drei Zeichen und zwei Rechnungssteller. Zwei Zeilen zu
viel sind harmlos; eine falsche Gruppe verbirgt einen Vertrag.

Nichts behaupten, was nicht belegt ist. Statt "monatlich" steht dort
"6 Zahlungen, etwa monatlich". Schwankt der Betrag, wird die Spanne
genannt. Ohne erkennbaren Abstand wird nicht hochgerechnet, sondern
gezeigt, was geflossen ist.

Dazu eine zweite Liste fuer einzelne groessere Zahlungen: Die
Gruppierung braucht zwei Zahlungen, ein Jahresbeitrag erscheint bei
einem importierten Jahr aber nur einmal - und ausgerechnet
Versicherungen zahlt man oft jaehrlich.

Geprueft: 37 Einheitstests, die Haelfte davon in der Gegenrichtung, plus
vier End-to-End-Tests auf beiden Geraeteprofilen. Der Browsertest hat
zwei Fehler gefunden, die Typpruefung und Einheitstests durchgelassen
haben - darunter ein verlorener Backslash, der die Vorbelegung des
Beitrags stillschweigend verschluckte.

Nebenbei: .claude/ ins .gitignore. Dort legen parallel arbeitende
Agenten ihre Worktrees ab; ein "git add -A" haette einen kompletten
zweiten Checkout eingecheckt.

Refs #3

prisma/schema.prisma

@@ -312,6 +312,7 @@ model Betreute {
   dokumente             Dokument[]
   konten                Konto[]
   buchungen             Buchung[]
+  zahlungsgruppen       ZahlungsgruppeGeklaert[]
   vermoegensposten      Vermoegensposten[]
   immobilien            Immobilie[]
   vertraege             Vertrag[]
@@ -828,6 +829,42 @@ enum BuchungKategorie {
   UMBUCHUNG
 }
 
+/// Eine Gruppe wiederkehrender Zahlungen, zu der bewusst KEIN Vertrag
+/// gefuehrt wird - Miete, Strom, Rundfunkbeitrag, Finanzamt.
+///
+/// Die Entscheidung haengt am normalisierten Namen der Gegenstelle, nicht
+/// an den Buchungen. Nur so ueberlebt sie den naechsten Kontoauszug: Beim
+/// Import entstehen neue Buchungszeilen, der Empfaenger bleibt derselbe.
+///
+/// ACHTUNG: Der Schluessel wird von normalisieren() in
+/// src/lib/finanzen/wiederkehrend.ts gebildet. Aendert sich diese Funktion,
+/// passen bestehende Schluessel nicht mehr und abgehakte Gruppen tauchen
+/// wieder auf. Das ist unangenehm, aber ungefaehrlich - schlimmer waere,
+/// eine Gruppe stillschweigend weiter zu verbergen, die inzwischen anders
+/// zugeschnitten ist.
+model ZahlungsgruppeGeklaert {
+  id String @id @default(cuid())
+
+  betreuteId String
+  betreute   Betreute @relation(fields: [betreuteId], references: [id], onDelete: Cascade)
+
+  /// Normalisierter Name der Gegenstelle.
+  schluessel String
+
+  /// Die Schreibweise, wie sie beim Abhaken auf dem Bildschirm stand -
+  /// damit spaeter noch erkennbar ist, worum es ging.
+  anzeigename String
+
+  /// Warum kein Vertrag? Freiwillig, aber in einem Jahr Gold wert.
+  begruendung String?
+
+  erstelltAm DateTime @default(now())
+
+  @@unique([betreuteId, schluessel])
+  @@index([betreuteId])
+  @@map("zahlungsgruppe_geklaert")
+}
+
 model Buchung {
   id String @id @default(cuid())