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).

rules/OPEN.md

@@ -54,4 +54,32 @@ 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.
+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.
+
+## 5. Fallback, wenn keine Datenklasse zutrifft
+
+Wenn ein Antrag bei allen B-Fragen "nein" beantwortet — auch bei B7
+("nur allgemein zugängliche/erfundene Inhalte") — trifft laut Tabelle
+keine Stufe zu (ein eigentlich widersprüchlicher Zustand: irgendeine
+Kategorie sollte immer zutreffen). `internal/rules.EvaluateDatenklasse`
+nimmt in diesem Fall konservativ `intern` an, nicht `oeffentlich` — im
+Zweifel mehr Schutzanforderungen, nicht weniger. **Nicht fachlich
+bestätigt**, nur eine sichere Standardannahme.
+
+## 6. Welche Anforderungen werden hart gegen ein Werkzeug gefiltert?
+
+`internal/rules.ErfuelltAnforderung` filtert aktuell hart nur
+`avv_erforderlich`, `eu_verarbeitung` und `kein_training_auf_eingabe` —
+das sind technische Eigenschaften eines Werkzeugs
+(`werkzeug.avv_verfuegbar`, `verarbeitungsort`, `training_standard`).
+`menschliche_aufsicht`, `kennzeichnungspflicht` und `dsfa_erforderlich`
+betreffen dagegen einen Prozess rund um die Nutzung, nicht das Werkzeug
+selbst — ein Werkzeug wird deswegen nicht aussortiert, das wird
+stattdessen als Auflage vermerkt (geplant für Schritt 4/5). **Diese
+Aufteilung ist eine Annahme von Schritt 3, nicht ausdrücklich in der
+Spezifikation so festgelegt** — vor Schritt 4 gegenprüfen, ob das der
+gewünschten Produktlogik entspricht.