feat: Posteingang und Entscheiden für die Fachebene (Schritt 5 der Baureihenfolge)

Ebene 3 (Rollen verantwortlicher/pruefer) bekommt GET /faelle
(Posteingang aller offenen Anträge des Mandanten) und GET/POST
/faelle/{id} zum Entscheiden. Eine Entscheidung friert Regelwerk-,
Katalog- und den vollständigen Werkzeugdatensatz ein, verlangt eine
Begründung bei Abweichung vom abgeleiteten Vorschlag, erlaubt bei
Genehmigung nur ein durch die Bewertung zulässiges Werkzeug und
protokolliert die Entscheidung im Audit-Log. entscheidung ist
append-only wie bewertung.

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

CLAUDE.md

@@ -205,23 +205,45 @@ mehrfacher Neubewertung eines Antrags erhalten bleibt.
 
 ---
 
-## Entscheidung, Register, Wiedervorlage (geplant, Schritt 5-7)
+## Entscheidung, Register, Wiedervorlage (Schritt 5 erledigt, Schritt 6-7 geplant)
+
+**Schritt 5 (Entscheidung, Snapshot, Audit-Log) ist umgesetzt.** Ebene 3
+(Fachebene) hat einen Posteingang (`GET /faelle`, alle offenen —
+Status "eingereicht" — Anträge des Mandanten, nicht nur die eigenen)
+und eine Entscheiden-Seite (`GET /faelle/{id}`, `POST
+/faelle/{id}/entscheiden`, siehe `internal/web/fachebene_handlers.go`).
+Rollen `verantwortlicher` und `pruefer` sehen dieselbe Sicht
+(`requireFachebene`), nur `verantwortlicher` hat Entscheidungsrecht —
+ein `pruefer`-POST auf `/entscheiden` bekommt 403 (er darf wissen, dass
+der Fall existiert, nur nicht entscheiden; anders als bei
+`requireFachebene`/`requireBetreiber`, die bei falscher Rolle 404
+liefern, um die Existenz der Seite selbst zu verbergen).
 
 Der/die Verantwortliche wählt: genehmigt / genehmigt mit Auflagen /
-abgelehnt / Rückfrage. Begründungsfeld ist bei Abweichung vom Vorschlag
-Pflicht. **Snapshot bei Entscheidung:** Regelwerk-Version, Katalog-
-Version und der vollständige Werkzeugdatensatz werden eingefroren — ein
-späterer Katalog-Wandel darf nicht rückwirkend verändern, worauf eine
-Entscheidung beruhte.
+abgelehnt / Rückfrage. **Vorschlag-Vergleich:** `vorschlagFuer` leitet
+aus der Bewertung ab, was das System vorschlagen würde (`abgelehnt` bei
+`verboten`, sonst `genehmigt` wenn mindestens ein zulässiges Werkzeug
+existiert, sonst `rueckfrage`) — weicht die tatsächliche Entscheidung
+davon ab, ist das Begründungsfeld Pflicht (sonst 400). **Snapshot bei
+Entscheidung:** `entscheidung.werkzeug_snapshot` (JSONB) friert den
+vollständigen `store.Werkzeug`-Datensatz zum Entscheidungszeitpunkt ein
+— ein späterer Katalog-Wandel darf nicht rückwirkend verändern, worauf
+eine Entscheidung beruhte. Bei "genehmigt"/"genehmigt mit Auflagen" ist
+ein Werkzeug aus der zulässigen Liste der Bewertung Pflicht (hart
+geprüft, kein Override eines ausgeschlossenen Werkzeugs). `entscheidung`
+ist append-only (Migration 0010) wie `bewertung`; jede Entscheidung
+erzeugt zusätzlich einen `audit_log`-Eintrag (Action
+`antrag_entschieden`).
 
-Genehmigungen erhalten ein Ablaufdatum (Vorschlag: 12 Monate, bei
-`hochrisiko` 6). Ändert sich im Katalog eine Eigenschaft, auf der eine
-aktive Genehmigung beruht, wird der/die Verantwortliche benachrichtigt
-(Wiedervorlage).
+Genehmigungen erhalten ein Ablaufdatum (`gueltig_bis`: 12 Monate, bei
+`hochrisiko` 6 — `gueltigkeitFuer`). **Noch nicht gebaut (Schritt 7):**
+die Benachrichtigung, wenn sich im Katalog eine Eigenschaft ändert, auf
+der eine aktive Genehmigung beruht (Wiedervorlage).
 
-Jede Genehmigung erzeugt automatisch einen Registereintrag: Zweck,
-Abteilung, Werkzeug, Datenklasse, Einstufung, Auflagen, Verantwortliche/
-r, Datum, Gültigkeit. Export als PDF und CSV.
+**Noch nicht gebaut (Schritt 6):** ein `registereintrag` wird bislang
+NICHT automatisch aus einer Genehmigung erzeugt, und es gibt keinen
+PDF-/CSV-Export. Geplant: Zweck, Abteilung, Werkzeug, Datenklasse,
+Einstufung, Auflagen, Verantwortliche/r, Datum, Gültigkeit.
 
 ---
 
@@ -305,12 +327,16 @@ nicht anzulegen. Noch nicht gebaut (kein Abo-System).
   NICHT append-only (normale Zustandsänderung `entwurf` →
   `eingereicht` → `entschieden`, wie `submission` es im alten Produkt
   war).
-- `bewertung`, `entscheidung`, `registereintrag` — **noch nicht
-  gebaut**, geplant für Schritt 5/6 der Baureihenfolge.
+- `bewertung` — der berechnete Vorschlag (Schritt 4).
+- `entscheidung` — die Entscheidung eines/einer Verantwortlichen über
+  einen Antrag, mit Snapshot des gewählten Werkzeugs (`werkzeug_snapshot`,
+  JSONB) und Ablaufdatum (`gueltig_bis`) bei Genehmigung (Schritt 5).
+- `registereintrag` — **noch nicht gebaut**, geplant für Schritt 6.
 
 **Append-only:** kein UPDATE auf `audit_log` (Trigger `forbid_update_delete`,
-wiederverwendet aus dem alten Produkt). `bewertung`/`entscheidung`/
-`registereintrag` werden bei ihrer Einführung ebenfalls append-only.
+wiederverwendet aus dem alten Produkt), ebenso `bewertung` und
+`entscheidung`. `registereintrag` wird bei seiner Einführung ebenfalls
+append-only.
 
 ---
 
@@ -341,7 +367,15 @@ wiederverwendet aus dem alten Produkt). `bewertung`/`entscheidung`/
    `bewertung` ist append-only. Getestet inkl. K.-o.-Prüfung
    (`verboten` überspringt die Werkzeugsuche) und hartem Filter
    gegen den Katalog.)
-5. Entscheidung, Snapshot, Audit-Log
+5. ~~Entscheidung, Snapshot, Audit-Log~~ — **erledigt** (Ebene 3:
+   `GET /faelle` Posteingang, `GET /faelle/{id}` + `POST
+   /faelle/{id}/entscheiden`. `verantwortlicher` entscheidet,
+   `pruefer` sieht dieselbe Seite ohne Entscheidungsrecht [403 bei
+   Entscheidungsversuch]. Begründung ist Pflicht bei Abweichung vom
+   abgeleiteten Vorschlag (`vorschlagFuer`), Genehmigung friert den
+   vollständigen Werkzeugdatensatz ein und braucht ein zulässiges
+   Werkzeug aus der Bewertung, `entscheidung` ist append-only, jede
+   Entscheidung erzeugt einen `audit_log`-Eintrag.)
 6. Registereintrag und Export
 7. Wiedervorlage und Katalog-Benachrichtigung