feat: Ableitungen und harte Filter (Schritt 3 der Baureihenfolge)

Reine Auswertungslogik in internal/rules, operiert auf rules.Antworten
(geparst aus antrag.antworten) und den drei Regelwerken aus Schritt 1
— ohne DB-/Web-Zugriff, vollständig isoliert testbar.

- EvaluateDatenklasse: "höchste zutreffende Stufe gewinnt" (höherer
  Rang). Trifft keine Stufe zu (z. B. B7 fälschlich "nein" trotz keiner
  anderen Kategorie), wird konservativ "intern" angenommen statt
  "oeffentlich" — im Zweifel mehr Schutz. Nicht fachlich bestätigt,
  siehe rules/OPEN.md Punkt 5.
- EvaluateEinstufung: Prüfreihenfolge wie im Regelwerk (verboten zuerst
  = K.-o.-Prüfung), erste zutreffende Stufe/Variante gewinnt.
  IstVerboten prüft die K.-o.-Bedingung direkt.
- DeriveAnforderungen: Anforderungsprofil aus Datenklasse+Einstufung.
- FilterWerkzeuge/ErfuelltAnforderung: harter Filter gegen einen
  Werkzeugkatalog. WerkzeugEigenschaften ist ein eigener, schlanker Typ
  statt store.Werkzeug — internal/rules bleibt unabhängig von
  internal/store. Nur technische Werkzeug-Eigenschaften
  (avv_erforderlich, eu_verarbeitung, kein_training_auf_eingabe) werden
  hart gefiltert; Prozess-Anforderungen (menschliche_aufsicht,
  kennzeichnungspflicht, dsfa_erforderlich) sortieren kein Werkzeug
  aus, sondern werden später als Auflage vermerkt — Annahme, siehe
  rules/OPEN.md Punkt 6.

rules/OPEN.md um Punkt 4 (Auswirkung der fehlenden Löschfristen auf den
Filter), Punkt 5 (Datenklasse-Fallback) und Punkt 6 (welche
Anforderungen hart filtern) ergänzt — Annahmen dokumentiert statt
geraten, damit Schritt 3 nicht auf die fachliche Klärung warten musste.

16 neue Tests gegen die ECHTEN rules/*.yaml-Dateien (nicht nur
synthetische Fixtures) — deckt Rang-Konflikte, "Unsicher zählt wie Ja",
alle vier Einstufungsstufen inkl. Auffangregel, Anforderungs-Ableitung
und Werkzeug-Filterung ab. Noch nicht ans Web angebunden (Schritt 4).

CLAUDE.md

@@ -139,11 +139,18 @@ Werkzeug: `avv_erforderlich`, `eu_verarbeitung`,
 `menschliche_aufsicht`, `kennzeichnungspflicht`, `dsfa_erforderlich`.
 
 `internal/rules` lädt und validiert diese drei Dateien (eindeutige IDs,
-eindeutige Ränge, jede Anforderung braucht mindestens einen Auslöser).
-**Die Auswertung gegen echte Fragebogen-Antworten ist noch nicht
-gebaut** — das ist Schritt 3 der Baureihenfolge (siehe unten), bewusst
-erst, wenn der Fragebogen (Schritt 2) die exakten Fakten-Feldnamen
-festlegt.
+eindeutige Ränge, jede Anforderung braucht mindestens einen Auslöser)
+und wertet sie seit Schritt 3 auch aus: `EvaluateDatenklasse`,
+`EvaluateEinstufung`, `IstVerboten`, `DeriveAnforderungen` operieren auf
+`rules.Antworten` (geparst aus `antrag.antworten` via `ParseAntworten`)
+— reine, für sich getestete Funktionen ohne DB-/Web-Zugriff.
+`FilterWerkzeuge`/`ErfuelltAnforderung` filtern einen Werkzeugkatalog
+hart gegen die abgeleiteten Anforderungen (`WerkzeugEigenschaften` ist
+ein schlanker, von `store.Werkzeug` unabhängiger Typ, damit
+`internal/rules` weiterhin ohne `internal/store` auskommt). **Noch
+nicht verdrahtet:** eine Web-Seite, die das für einen konkreten Antrag
+tatsächlich aufruft und anzeigt — das ist Schritt 4
+("Ergebnisdarstellung mit Herleitung").
 
 ---
 
@@ -318,7 +325,10 @@ wiederverwendet aus dem alten Produkt). `bewertung`/`entscheidung`/
    JavaScript. `antworten`-JSON nutzt exakt die Fakten-Schlüssel aus
    `rules/*.yaml` (b1-b7, c1-c5, c2_folge, c3_art) — das hat auch die
    OPEN.md-Frage zu den "verboten"-Fragebogen-Feldern final geklärt.)
-3. Ableitungen und harte Filter (Auswertung gegen echte Antworten)
+3. ~~Ableitungen und harte Filter~~ — **erledigt** (`internal/rules`:
+   `EvaluateDatenklasse`/`EvaluateEinstufung`/`DeriveAnforderungen`/
+   `IstVerboten`/`FilterWerkzeuge`, vollständig getestet gegen die
+   echten `rules/*.yaml`-Dateien. Noch nicht ans Web angebunden.)
 4. Ergebnisdarstellung mit Herleitung
 5. Entscheidung, Snapshot, Audit-Log
 6. Registereintrag und Export
@@ -532,8 +542,11 @@ journalctl -u deklarix -f
 ## Offene Punkte
 
 - **Rangfolge der Datenklassen und Grenzfälle im Anforderungsprofil**
-  (siehe `rules/OPEN.md`) — vor Schritt 3 mit dem/der fachlich
-  Verantwortlichen (z. B. Datenschutzbeauftragte/r) bestätigen.
+  (siehe `rules/OPEN.md`, Punkte 1/2/5/6) — mit dem/der fachlich
+  Verantwortlichen (z. B. Datenschutzbeauftragte/r) bestätigen. Schritt
+  3 ist trotzdem schon umgesetzt (auf Basis dieser dokumentierten
+  Annahmen) — nicht auf die Klärung gewartet, um nicht blockiert zu
+  bleiben, aber die Ableitung kann sich noch ändern.
 - ~~Genaue Fragebogen-Felder für die drei "verboten"-Varianten~~ —
   **erledigt in Schritt 2**, C3 hat jetzt eine Folgefrage `c3_art`.
   Weiterhin offen: ob die drei Varianten fachlich vollständig sind