fix: Ersteinrichtung liess sich nicht abschliessen, Betreute nicht loeschen

Zwei Fehler, beide erst im Betrieb sichtbar.

1. Schritt 3 der Ersteinrichtung meldete "Bitte pruefe die markierten
   Felder" - und markierte keines. Man kam dort nicht weiter.

   Das kurze Formular schickt neun Felder, das vollstaendige unter
   Stammdaten alle. Beide gehen durch dasselbe Schema, und die optionalen
   Felder waren zwar nullable, aber nicht optional: Ein Feld, das gar
   nicht abgeschickt wurde, ist undefined, nicht null. Beanstandet wurden
   also zwei Dutzend Felder, die auf dem Bildschirm nie standen.

   Damit das nicht wiederkommt, unterscheidet die Aktion jetzt zwischen
   Eingabefehler und Formular-Schema-Bruch: Beanstandet die Pruefung ein
   Feld, das nicht abgeschickt wurde, sagt sie das ausdruecklich und
   schreibt es ins Serverlog, statt es dem Nutzer als Eingabefehler
   unterzuschieben, den er nirgends finden kann.

2. Eine betreute Person liess sich nicht endgueltig loeschen. Postgres
   setzt beim Loeschen den Verweis im Audit-Log auf NULL, und genau
   dieses UPDATE hat der Unveraenderlichkeits-Trigger abgewiesen. Damit
   scheiterte auch das Leeren des Papierkorbs nach 30 Tagen.

   Der Trigger erlaubt jetzt genau eine Ausnahme: das Nullen der beiden
   Fremdschluessel. Jede andere Aenderung bleibt verboten, auch das
   Setzen eines Fremdschluessels auf einen anderen Wert. Der Nachweis
   bleibt vollstaendig - es verschwindet nur der Verweis auf einen
   Datensatz, den es nicht mehr gibt.

Geprueft: sieben neue Tests gegen die tatsaechlichen Formularinhalte, der
Ablauf einmal komplett im Browser bis zum Dashboard, und der Trigger
gegen eine laufende Datenbank - Loeschen gelingt, Faelschen scheitert.

Etappe: 8
Phase: Haertung

CHANGELOG.md

@@ -26,6 +26,61 @@ Wiederherstellung*.
 
 _Noch nichts._
 
+## [1.0.4] – 2026-08-22
+
+### Behoben
+
+- **Die Ersteinrichtung ließ sich nicht abschließen.** Schritt 3 meldete
+  „Bitte prüfe die markierten Felder" — markierte aber keines. Man kam an
+  dieser Stelle nicht weiter.
+
+  Ursache: Das kurze Formular der Ersteinrichtung schickt neun Felder, das
+  vollständige unter *Stammdaten* alle. Beide gehen durch dasselbe Schema,
+  und die optionalen Felder waren zwar `nullable`, aber nicht `optional` —
+  ein Feld, das gar nicht abgeschickt wurde, ist `undefined`, nicht
+  `null`. Beanstandet wurden also zwei Dutzend Felder, die auf dem
+  Bildschirm nie standen.
+
+- **Eine Meldung ohne zugehöriges Feld kann nicht mehr unsichtbar
+  bleiben.** Beanstandet die Prüfung ein Feld, das das Formular gar nicht
+  gesendet hat, sagt die Anwendung das jetzt ausdrücklich und schreibt es
+  ins Serverlog — statt es als Eingabefehler auszugeben, den niemand
+  finden kann. Das ist ein Fehler im Programm, und er soll auch so
+  aussehen.
+
+- **Eine betreute Person ließ sich nicht endgültig löschen.** Beim Löschen
+  setzt Postgres den Verweis im Audit-Log auf NULL (`ON DELETE SET NULL`),
+  und genau dieses UPDATE hat der Unveränderlichkeits-Trigger abgewiesen.
+  Betroffen war damit auch das Leeren des Papierkorbs nach 30 Tagen und
+  das Entfernen des Demofalls.
+
+  Der Trigger erlaubt jetzt genau eine Ausnahme: das Nullen der beiden
+  Fremdschlüssel `betreuteId` und `userId`. Jede andere Änderung bleibt
+  verboten, auch das Setzen eines Fremdschlüssels auf einen **anderen**
+  Wert. Der Nachweis bleibt vollständig — Zeitpunkt, Aktion, Bezeichnung,
+  die verschlüsselte Änderung und die Momentaufnahmen von Name und
+  E-Mail sind unberührt. Es verschwindet nur der Verweis auf einen
+  Datensatz, den es nicht mehr gibt.
+
+  **Beim Update nötig:** das SQL-Skript erneut ausführen, sonst bleibt der
+  alte Trigger stehen.
+
+  ```bash
+  docker compose exec app node node_modules/prisma/build/index.js db execute     --schema prisma/schema.prisma --file prisma/sql/audit-schutz.sql
+  ```
+
+### Geprüft
+
+- Sieben neue Tests (`tests/stammdaten.test.ts`) prüfen genau die
+  Formularinhalte der Ersteinrichtung, dazu das vollständige Formular mit
+  leeren Feldern und die weiterhin verlangten Pflichtangaben.
+- Der Ablauf ist zusätzlich im Browser durchgespielt worden: Anmeldung,
+  zweiter Faktor, Schritt 3, Landung auf dem Dashboard — und die daraus
+  abgeleiteten Pflichtfristen samt Ausschlussfrist für die
+  Aufwandspauschale.
+- Der geänderte Trigger ist gegen eine laufende Datenbank geprüft:
+  Löschen gelingt, Fälschen und Löschen von Einträgen scheitert weiterhin.
+
 ## [1.0.3] – 2026-08-22
 
 Keine Änderung am Programm — nur an der Konfigurationsvorlage und der
@@ -296,7 +351,8 @@ Was davon wann angegangen wird, steht in [`docs/ROADMAP.md`](docs/ROADMAP.md).
 
 ---
 
-[Unveröffentlicht]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.3...HEAD
+[Unveröffentlicht]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.4...HEAD
+[1.0.4]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.3...v1.0.4
 [1.0.3]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.2...v1.0.3
 [1.0.2]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.1...v1.0.2
 [1.0.1]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.0.0...v1.0.1