Ansprechpartner am Vorgang hinterlegen

Ein namentlich adressiertes Schreiben landet bei der Person, die den
Vorgang kennt, statt in der Poststelle. Am Vorgang laesst sich jetzt ein
Kontakt aus dem Verzeichnis als Ansprechpartner benennen; die
Sachstandsanfrage redet ihn an, und sein Name steht ueber der Behoerde.

Die Sachstandsanfrage konnte das schon - sie bekam den Namen nur nie
uebergeben. entwurf.ts lud einen der verknuepften Kontakte und verwarf
ihn wieder. Wer angeredet wird, ist jetzt eine Entscheidung und kein
Zufall.

Aufbau:
- Migration: ansprechpartnerId am Vorgang (SetNull - ein Vorgang darf
  nicht daran haengen, dass es den Kontakt noch gibt) und anrede am
  Kontakt.
- Die Anrede als reine Funktion in kontakte/anrede.ts. Geraten wird nie:
  ohne hinterlegte Anrede wird mit vollem Namen angeredet. Ein leerer
  Name mit gesetzter Anrede faellt auf die allgemeine Anrede zurueck -
  "Sehr geehrte Frau ," darf nie herausgehen.
- Der Wechsel des Ansprechpartners steht mit NAMEN im Protokoll. Zwei
  cuids nebeneinander waeren protokolliert, aber nicht nachvollziehbar,
  und nachvollziehbar war die Anforderung.
- Der Ansprechpartner wird gegen die Akte geprueft, bevor er gespeichert
  wird - sein Name steht anschliessend im Briefkopf.

Nebenbei behoben: Der Schreiben-Editor verwarf die empfaengerAnschrift
aus dem Entwurf, sein State startete immer leer. Jetzt kommt die
Anschrift des Ansprechpartners im Formular an.

Geprueft: neun Einheitstests fuer die Anrede, fuenf End-to-End-Tests von
der Auswahl bis zum Protokolleintrag.

Refs #9

docs/INSTALLATION.md

@@ -131,14 +131,14 @@ cd /opt/betreuungs-cockpit
 
 # Auf die letzte veröffentlichte Fassung wechseln,
 # nicht auf den laufenden Entwicklungsstand
-git checkout v1.8.0
+git checkout v1.9.0
 ```
 
 ### Kontrolle
 
 ```bash
 ls docker-compose.yml Dockerfile .env.example   # alle drei da
-git describe --tags                              # v1.8.0
+git describe --tags                              # v1.9.0
 ```
 
 ---
@@ -299,7 +299,7 @@ betreuungs-cockpit-sicherung-1  Up
 ```bash
 # Antwortet die Anwendung? (Port anpassen, falls du APP_PORT gesetzt hast)
 curl -s http://127.0.0.1:3000/api/gesundheit
-# {"status":"bereit","version":"1.8.0","commit":"..."}
+# {"status":"bereit","version":"1.9.0","commit":"..."}
 ```
 
 Kommt hier nichts, sieh in die Logs:
@@ -649,7 +649,7 @@ Erst **vom Proxy-Server aus** — kommt er überhaupt an?
 
 ```bash
 curl -s http://10.0.0.5:3000/api/gesundheit
-# {"status":"bereit","version":"1.8.0",...}
+# {"status":"bereit","version":"1.9.0",...}
 ```
 
 Kommt hier nichts, liegt es an 7a: falsche `APP_BIND`, Firewall, oder der
@@ -700,7 +700,7 @@ Zum Schluss: **Fristen → Pflichtfristen ableiten**.
 - Du kommst mit E-Mail, Passwort und dem Code aus der App herein.
 - Unter **Fristen** stehen Einträge mit Paragraphenbezug.
 - Unter **Protokoll** siehst du deine eigene Anmeldung.
-- Unten links in der Seitenleiste steht `Version 1.8.0 · <commit>`.
+- Unten links in der Seitenleiste steht `Version 1.9.0 · <commit>`.
 
 ---
 
@@ -875,7 +875,7 @@ alles so vor wie zuvor.
 | Aufruf | Wirkung |
 |---|---|
 | `./scripts/update.sh` | auf die neueste veröffentlichte Fassung |
-| `./scripts/update.sh v1.8.0` | auf eine bestimmte Fassung |
+| `./scripts/update.sh v1.9.0` | auf eine bestimmte Fassung |
 | `./scripts/update.sh --pruefen` | nur nachsehen, nichts ändern |
 | `./scripts/update.sh --ja` | ohne Rückfrage (für cron) |
 | `./scripts/update.sh --verwerfen` | eigene Änderungen wegwerfen statt beiseitelegen |
@@ -913,7 +913,7 @@ git fetch --tags
 git log --oneline HEAD..origin/main
 
 # 3. Umschalten
-git checkout v1.8.0
+git checkout v1.9.0
 
 # 4. Neu bauen und starten
 GIT_COMMIT=$(git rev-parse --short HEAD) BUILD_ZEIT=$(date -Iseconds) docker compose up -d --build