Phase 5 abgeschlossen: Dateien mit vollständiger Prüfkette

Upload → quarantine/ → Typprüfung → ClamAV → Neukodierung → store/. Es gibt
keinen Pfad, auf dem eine Datei ungeprüft in store/ landet, und keinen
Schalter, der die Kette abschaltet.

Die Typprüfung liest Magic Bytes aus einer eigenen Signaturtabelle statt aus
file-type: bei einer Positivliste aus fünf Formaten hilft es nicht, hundert
erkennen zu können. Die Signatur muss an Position 0 stehen — ein Vorspann vor
%PDF- ist der klassische Weg, eine Datei für zwei Programme zugleich lesbar zu
machen. Wer trotzdem durchkommt, kommt als text/plain durch und wird unter der
Endung des erkannten Typs ausgeliefert, nicht unter der hochgeladenen.

Drei Ausgänge statt zwei: BLOCKED heisst "ist gefährlich", FAILED heisst
"wissen wir nicht". Nur FAILED lässt sich freigeben, und die Freigabe
wiederholt die Kette ohne den Scanner — Typprüfung und Neukodierung laufen
dabei mit. Ein fehlender clamd macht damit keine Datei sauber; ein Test hält
das fest.

Auslieferung nur über /api/files/[id], mit Sichtbarkeitsprüfung der
zugehörigen Akte, Protokoll ab Stufe 3 und den harten Kopfzeilen aus docs/07.
Vorschaubilder dürfen inline, weil sie serverseitig als WebP neu kodiert
wurden.

Das Lichtbild im Aktenblatt ist damit gefüllt: der Feldwert ist die Kennung
eines geprüften Anhangs, serverseitig zu einer Adresse aufgelöst.

/api/events liefert attachment.scanned über pg_notify — die Grundlage, auf der
Phase 6 den Aktenchat aufsetzt. Die Sichtbarkeit wird je Ereignis geprüft,
sonst verriete schon die Kennung die Existenz.

Nebenbei riss das Bündelbudget (121 kB gegen 120 erlaubte): lib/i18n/de.ts war
ein Objekt, und eine Client-Komponente zieht die ganze Datei mit. Die Texte
stehen jetzt in sechs Dateien nach Bereichen, de.ts setzt sie nur zusammen.
Grösste Route wieder bei 118 kB, und sie wächst nicht mehr mit jedem neuen
Bereich mit.

133 Tests im Web-Paket, 15 in der Datenbank, 28 e2e.

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

docs/13-entscheidungen.md

@@ -469,3 +469,84 @@ zusammen — dieselbe Prüfung, derselbe Protokolleintrag.
 Der Unterschied liegt in der Auswahl: auf der Fallakte eine Liste der sichtbaren Personen, auf
 der Personalakte ein Eingabefeld für das Aktenzeichen. Eine Liste aller sichtbaren Fälle auf
 einer Personalakte wäre am falschen Ort — sie beantwortet nicht die Frage, die man dort hat.
+
+## Dateien
+
+### Eigene Signaturtabelle statt `file-type`
+
+`docs/07-dateien-und-sicherheit.md` nennt die Bibliothek `file-type`. Gebaut wurde eine
+eigene Tabelle in `web/lib/files/magic.ts`, aus drei Gründen:
+
+- Die Liste der erlaubten Typen ist **kurz und geschlossen**. Bei einer Positivliste hilft es
+  nicht, hundert Formate erkennen zu können — was nicht in der Tabelle steht, fliegt ohnehin
+  raus.
+- Der eigentliche Schutz ist nicht die Erkennung, sondern die **Neukodierung** danach. Ein
+  Bild, das durch `sharp` gelaufen ist, besteht nur noch aus Pixeln.
+- Eine Abhängigkeit weniger, die auf einem Heimserver aktuell gehalten werden muss.
+
+Die Tabelle ist streng: die Signatur muss an Position 0 stehen. Ein Vorspann vor `%PDF-` ist
+der klassische Weg, eine Datei für zwei Programme zugleich lesbar zu machen; die
+PDF-Spezifikation erlaubt ihn, wir nicht.
+
+### `text/plain` ist das Schlupfloch, und deshalb eng
+
+Reiner Text hat keine Signatur. Er wird zuletzt geprüft und nur angenommen, wenn der **ganze**
+Inhalt gültiges UTF-8 ohne Steuerzeichen ist. Sonst wäre `text/plain` der Weg, durch den jedes
+Binärformat passt.
+
+Eine Folge davon: eine Datei, die sowohl lesbarer Text als auch ein PDF sein will, wird als
+Text erkannt. Sie wird deshalb **unter der Endung des erkannten Typs ausgeliefert** — aus
+`bericht.pdf` wird `bericht.txt`. Damit landet sie beim Doppelklick in keinem PDF-Betrachter.
+Die Endung folgt grundsätzlich dem erkannten Typ, nie dem hochgeladenen Namen.
+
+### Ein ausgefallener Scanner macht eine Datei nicht sauber
+
+Drei Ausgänge statt zwei:
+
+| Zustand | Bedeutung |
+|---|---|
+| `BLOCKED` | Als Schadsoftware oder unzulässiger Typ **erkannt**. Endgültig |
+| `FAILED` | Die Prüfung konnte nicht abgeschlossen werden — Scanner weg, `qpdf` fehlt, Zeitüberschreitung |
+| `CLEAN` | Die ganze Kette bestanden |
+
+Der Unterschied zwischen `BLOCKED` und `FAILED` ist der zwischen „ist gefährlich" und „wissen
+wir nicht". Nur das Zweite lässt sich von einem Administrator freigeben, und diese Freigabe
+wiederholt die Kette **ohne den Scanner**: die Typprüfung und die Neukodierung laufen dabei
+mit. Übersprungen wird nur, was ausgefallen war.
+
+Damit gibt es keinen Schalter, der die Prüfung abschaltet. In der Entwicklung ohne
+clamav-Container landet jeder Upload auf `FAILED` und wird von Hand freigegeben — unbequem,
+aber ehrlich. Eine Umgebungsvariable, die Dateien ungeprüft durchwinkt, wäre genau die Art
+Abkürzung, die irgendwann in der Produktion steht.
+
+### Das Lichtbild ist eine Kennung, kein Bild
+
+Der Wert eines `photo`-Feldes ist die Kennung eines geprüften Anhangs. Die Vorlage der
+Abteilung legt das Bild als Data-URL ab; im Abschnittswert wäre das eine ungeprüfte Datei
+mitten im Aktentext, die sich nachträglich kaum wieder herausbekommen liesse.
+
+Aufgelöst wird **serverseitig**: der Browser bekommt eine Adresse oder gar nichts, nie eine
+Kennung zum Ausprobieren.
+
+### Die Verarbeitung läuft im Web-Dienst
+
+`compose.yaml` hängt das Dateivolumen und den clamd-Socket an `web`, nicht an `worker` — die
+Prüfkette läuft deshalb dort, angestossen nach der Antwort auf den Upload. Der Nutzer sieht
+den Anhang sofort mit „Wird geprüft"; der Fortschrittsbalken zeigt allein die Übertragung.
+Kein Balken wartet auf einen Virenscanner, siehe docs/09-performance-und-ux.md.
+
+## Die Oberflächentexte sind nach Bereichen getrennt
+
+`lib/i18n/de.ts` war ein einziges Objekt. Eine Client-Komponente zieht aber die **ganze
+Datei** ins Bündel, in der ihr Text steht — jede Ansicht trug damit die Texte aller anderen
+mit sich herum. Mit Phase 5 riss das Budget aus `docs/09-performance-und-ux.md`: 121 kB gegen
+120 kB erlaubte.
+
+Die Texte stehen jetzt in sechs Dateien nach Bereichen (`shell`, `common`, `cases`, `people`,
+`documents`, `admin`), und `de.ts` setzt sie nur noch zusammen. Serverkomponenten nehmen
+weiter `de` — was dorthin gezogen wird, verlässt den Server nicht. Client-Komponenten
+importieren den Bereich, den sie brauchen.
+
+Das brachte die grösste Route von 121 auf 118 kB und wächst nicht mehr mit jedem neuen
+Bereich mit. Der Zuschnitt der sechs Gruppen folgt der gemeinsamen Verwendung, nicht der
+Grösse: was zusammen gebraucht wird, liegt zusammen.