feat: Löschfristen je Datenklasse, Passwort-Zurücksetzen, DPF-Recherche

- Löschfristen (Migration 0020): pro Mandant einstellbar statt fest im
  Regelwerk, da die DSGVO selbst keine festen Fristen nennt (Art. 5
  Abs. 1 lit. e). Jede Firma wird mit risikogestaffelten Vorschlagswerten
  vorbelegt, loeschfrist_max_tage wird jetzt tatsächlich hart gegen
  Werkzeuge gefiltert (schließt rules/OPEN.md Punkt 4).
- Neues internal/mail-Paket (SMTP-Versand + Test-Doppel) und darauf
  aufbauend Passwort-Zurücksetzen (Migration 0019) - bisher nur als
  Absicht in der Rollentabelle genannt, nie gebaut.
- dpf_zertifiziert für alle 20 Katalogeinträge gegen das offizielle
  DPF-Register recherchiert und in der Produktions-DB aktualisiert
  (12 zertifiziert, 5 recherchiert-nicht-gefunden, 3 nicht anwendbar).

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

rules/OPEN.md

@@ -48,18 +48,28 @@ final, nicht mehr Platzhalter. Ob diese drei Varianten fachlich
 vollständig sind, wurde am 2026-08-29 vom Produktverantwortlichen
 **bestätigt (keine Ergänzung nötig).**
 
-## 4. `loeschfrist_max_tage` — konkrete Fristen je Datenklasse
+## 4. `loeschfrist_max_tage` — konkrete Fristen je Datenklasse — GELÖST (2026-09-01, konfigurierbar statt fest)
 
-Die Spezifikation nennt `loeschfrist_max_tage` als Anforderung "aus
-Datenklasse", ohne die konkreten Tageswerte pro Stufe zu nennen.
-`rules/anforderungen.yaml` listet die Anforderung nur als grundsätzlich
-anwendbar (welche Datenklassen sie überhaupt auslösen), ohne
-Zahlenwerte — die eigentlichen Fristen (z. B. "personenbezogen: 90
-Tage") müssen vor Phase 3 fachlich festgelegt werden. **Auswirkung auf
-Schritt 3 (`internal/rules.ErfuelltAnforderung`):** ohne Zahlenwerte
-wird diese Anforderung aktuell NICHT hart gegen Werkzeuge gefiltert
-(jedes Werkzeug gilt hier als "erfüllt") — sobald Fristen feststehen,
-muss die Filterfunktion entsprechend erweitert werden.
+Ursprünglich war unklar, wer die konkreten Tageswerte je Datenklasse
+festlegt. Recherche (2026-09-01) ergab: die DSGVO selbst nennt **keine**
+festen Speicherfristen — Art. 5 Abs. 1 lit. e verlangt nur, Daten "so
+lange wie für den Zweck nötig" zu speichern (Grundsatz der
+Speicherbegrenzung). Es gibt daher keinen einzelnen "richtigen"
+Zahlenwert, den man fest in `rules/anforderungen.yaml` hätte eintragen
+können. Lösung: **pro Mandant einstellbar**, vom Datenschutzbeauftragten
+festgelegt (`loeschfrist_einstellung`, Migration 0020, `GET/POST
+/verwaltung/loeschfristen`) statt einer globalen YAML-Konstante. Jede
+neue Firma wird mit risikogestaffelten Vorschlagswerten vorbelegt
+(`oeffentlich` 365 / `intern` 180 / `auftragsdaten` 90 / `personenbezogen`
+90 / `berufsgeheimnis` 30 / `besondere_kategorie` 30 Tage) — eigene
+Einschätzung, keine Rechtsvorgabe, frei editierbar.
+
+**Auswirkung auf Schritt 3 (`internal/rules.ErfuelltAnforderung`):** die
+Anforderung wird jetzt hart gefiltert, sobald für die betroffene
+Datenklasse eine Frist konfiguriert ist — ein Werkzeug ohne bezifferte
+Aufbewahrungsdauer erfüllt eine gesetzte Frist NICHT (fail closed, wie
+bei `eu_verarbeitung`). Ist keine Frist konfiguriert, bleibt das
+Verhalten wie zuvor (nicht gefiltert).
 
 ## 5. Fallback, wenn keine Datenklasse zutrifft — BESTÄTIGT (2026-08-29)