feat: Fragebogen mit adaptiver Logik (Schritt 2 der Baureihenfolge)

Ebene 2 ("Antrag stellen") als einseitiges Formular statt mehrseitigem
Assistenten — jede zusätzliche Seite kostet Zeit, und laut Spezifikation
wird ein Antrag umgangen, wenn er länger als fünf Minuten dauert.

- GET /antraege/neu: Fragebogen-Formular (Abschnitte A-D exakt nach
  Spezifikation). Adaptive Folgefragen (C2: welche Art von Entscheidung,
  C3: welche Art von Erkennung) werden rein per CSS :has() ein-/
  ausgeblendet, kein JavaScript nötig — visuell mit Chromium-Screenshots
  verifiziert (unchecked vs. checked).
- POST /antraege: legt an und reicht direkt ein (entwurf->eingereicht in
  einem Schritt, kein Zwischenspeichern als Entwurf für v1). Die
  antworten-JSON nutzt exakt dieselben Fakten-Schlüssel wie
  rules/*.yaml (b1-b7, c1-c5, c2_folge, c3_art) — Schritt 3 kann sie
  direkt auswerten, ohne Felder umzubenennen. "Unsicher" wird bewusst
  NICHT zu "ja" normalisiert (das ist eine Auswertungsregel für Schritt
  3, keine Speicherregel) — der Antrag hält fest, was der Mitarbeiter
  tatsächlich geantwortet hat.
- GET /antraege: eigene Anträge (Ebene 2 sieht nur eigene, nicht die
  des ganzen Mandanten — dafür neue Store-Methode
  ListAntraegeForUser, getrennt von ListAntraegeForAccount für den
  späteren Ebene-3-Posteingang).
- GET /antraege/{id}: Detail, fremder Antrag liefert 404 (nicht 403,
  gleiches Muster wie überall sonst im Projekt).
- betreiber-Rolle wird von allen Antrags-Routen weggeleitet (Ebene 5
  ist technisch getrennt vom Mandantenbereich).

rules/OPEN.md Punkt 3 (fehlende Fragebogen-Unterscheidung für die
"verboten"-Varianten) damit geklärt: c3_art existiert jetzt mit den
bereits in rules/kivo_einstufung.yaml erwarteten Werten.

Volle Testsuite inkl. echter Postgres-Tests grün; End-to-End gegen
einen laufenden Server verifiziert (Antrag anlegen, antworten-JSON in
der DB korrekt, Detail-/Listenansicht, Mandantentrennung).

CLAUDE.md

@@ -311,7 +311,13 @@ wiederverwendet aus dem alten Produkt). `bewertung`/`entscheidung`/
    `abteilung`/`werkzeug`/`werkzeug_sperre`/`antrag` in Postgres,
    `internal/rules` lädt und validiert die drei YAML-Regelwerke,
    Web-Layer kompiliert mit Auth + Plattform-Bereich-Gerüst).
-2. Fragebogen mit adaptiver Logik
+2. ~~Fragebogen mit adaptiver Logik~~ — **erledigt** (`GET /antraege/neu`
+   einseitiges Formular, `POST /antraege` legt an und reicht direkt ein,
+   `GET /antraege` eigene Anträge, `GET /antraege/{id}` Detail. Adaptive
+   Folgefragen C2/C3 rein per CSS `:has()` ein-/ausgeblendet, kein
+   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)
 4. Ergebnisdarstellung mit Herleitung
 5. Entscheidung, Snapshot, Audit-Log
@@ -528,9 +534,10 @@ journalctl -u deklarix -f
 - **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.
-- **Genaue Fragebogen-Felder für die drei "verboten"-Varianten** (KI-VO
-  Art. 5) — Fragebogen-Spezifikation nennt nur eine C3-Frage ohne die
-  nötige Unterscheidung, siehe `rules/OPEN.md`.
+- ~~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
+  (siehe `rules/OPEN.md`, Punkt 3).
 - **Löschfristen je Datenklasse** (konkrete Tageswerte für
   `loeschfrist_max_tage`) — noch nicht fachlich festgelegt.
 - **Mandantenisolation auf Datenbankebene (Postgres Row-Level Security)**