feat: Update-Skript, das die vergessenen Schritte mitnimmt

Bisher war Aktualisieren eine Folge von Befehlen aus der Anleitung, und
zwei davon vergisst man zuverlaessig: die Sicherung vorher und die beiden
SQL-Skripte hinterher. Genau die hat es hier schon gekostet.

./scripts/update.sh macht das in einem Durchgang - mit zwei
Eigenschaften, auf die es ankommt:

Bis zur Rueckfrage wird nichts veraendert. Der erste Entwurf hat die
eigenen Aenderungen beiseite gelegt und danach am Serverzugriff
abgebrochen - Halbzustand, aus dem man erst wieder herausfinden muss.
Jetzt laufen Pruefung, Abgleich und Changelog-Anzeige vollstaendig
durch, bevor irgendetwas angefasst wird.

Eigene Aenderungen an versionierten Dateien blockieren nicht. Im Betrieb
passt man die docker-compose.yml an, bis etwas laeuft; genau diese
Anpassungen sind spaeter oft schon eingearbeitet. Das Skript legt sie mit
git stash beiseite - rueckholbar, nicht weggeworfen - und sagt, wie man
sie zurueckbekommt. Wer sie wirklich loswerden will, nimmt --verwerfen.
Die .env bleibt immer unangetastet.

Schlaegt die Sicherung fehl, wird nicht aktualisiert. Schlaegt der Bau
fehl, nennt das Skript den Weg zurueck.

Nebenbei behoben: Der Port der MinIO-Konsole stand fest auf 9001. Lief
dort schon etwas, startete der ganze Stapel nicht. Jetzt ueber
MINIO_KONSOLE_PORT einstellbar - dieselbe Moeglichkeit, die APP_PORT
schon hatte. Aufgefallen beim Aufsetzen einer Testumgebung.

Etappe: 8
Phase: Haertung

docs/INSTALLATION.md

@@ -832,27 +832,80 @@ Denk an die letzten Pflichten:
 
 ## Aktualisieren
 
+```bash
+cd /opt/betreuungs-cockpit
+./scripts/update.sh
+```
+
+Das war es. Das Skript nimmt dir die Schritte ab, die man von Hand
+vergisst:
+
+1. Prüft Verzeichnis, git, docker und `.env`
+2. Holt die Fassungen und zeigt, was zwischen deinem Stand und dem neuen
+   im Changelog steht
+3. Fragt nach
+4. **Stößt eine Sicherung an** — und bricht ab, wenn sie nicht klappt
+5. Legt eigene Änderungen an versionierten Dateien beiseite, schaltet um,
+   baut neu
+6. Wartet, bis die Anwendung antwortet
+7. Führt die **beiden SQL-Skripte** aus (Volltextsuche, Audit-Schutz)
+8. Prüft, ob wirklich die neue Fassung läuft
+
+**Bis Schritt 3 wird nichts verändert.** Bricht etwas vorher ab, findest du
+alles so vor wie zuvor.
+
+### Aufrufmöglichkeiten
+
+| Aufruf | Wirkung |
+|---|---|
+| `./scripts/update.sh` | auf die neueste veröffentlichte Fassung |
+| `./scripts/update.sh v1.2.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 |
+| `./scripts/update.sh --ohne-sicherung` | Sicherung überspringen — sehr gut überlegen |
+
+### Eigene Änderungen an der docker-compose.yml
+
+Das ist der Normalfall: Man passt etwas an, bis es läuft. Das Skript legt
+solche Änderungen vor dem Umschalten mit `git stash` beiseite und sagt,
+wie man sie zurückholt:
+
+```bash
+git stash list      # was liegt da
+git stash pop       # zurückholen
+git stash drop      # wegwerfen
+```
+
+Sind deine Anpassungen inzwischen im Projekt eingearbeitet — wie
+`APP_BIND` oder `MINIO_KONSOLE_PORT` —, brauchst du sie nicht
+zurückzuholen. Dann setz die Werte einfach in der `.env`.
+
+> **Die `.env` wird nie angefasst.** Sie ist nicht versioniert; weder
+> `git checkout` noch das Skript rühren sie an.
+
+### Von Hand, wenn du lieber selbst steuerst
+
 ```bash
 cd /opt/betreuungs-cockpit
 
 # 1. IMMER zuerst sichern - eine Migration lässt sich nicht zurückrollen
 docker compose exec sicherung /bin/sh /sicherung.sh
 
-# 2. Was ändert sich? Lies den Changelog, bevor du ziehst
+# 2. Was ändert sich?
 git fetch --tags
 git log --oneline HEAD..origin/main
 
-# 3. Auf die neue Fassung wechseln
+# 3. Umschalten
 git checkout v1.1.0
 
 # 4. Neu bauen und starten
-GIT_COMMIT=$(git rev-parse --short HEAD) \
-BUILD_ZEIT=$(date -Iseconds) \
-docker compose up -d --build
-```
+GIT_COMMIT=$(git rev-parse --short HEAD) BUILD_ZEIT=$(date -Iseconds) docker compose up -d --build
 
-Die Migrationen laufen beim Start mit. **Sagt der Changelog, dass sich ein
-SQL-Skript geändert hat, führ die beiden Befehle aus Schritt 5 erneut aus.**
+# 5. Die beiden SQL-Skripte - sie laufen NICHT mit den Migrationen mit
+docker compose exec app node node_modules/prisma/build/index.js db execute   --schema prisma/schema.prisma --file prisma/sql/volltextsuche.sql
+docker compose exec app node node_modules/prisma/build/index.js db execute   --schema prisma/schema.prisma --file prisma/sql/audit-schutz.sql
+```
 
 ### Kontrolle
 
@@ -862,7 +915,21 @@ curl -s https://cockpit.deine-domain.de/api/gesundheit
 ```
 
 Steht dort noch die alte Version, läuft der alte Behälter weiter — dann
-hat der Bau nicht durchgezogen. Sieh in `docker compose logs app`.
+hat der Bau nicht durchgezogen:
+
+```bash
+docker compose up -d --build --force-recreate app
+```
+
+### Zurück auf den vorherigen Stand
+
+```bash
+git checkout v1.0.4
+docker compose up -d --build
+```
+
+Hat die neue Fassung die Datenbank migriert, reicht das nicht — dann muss
+auch die Sicherung zurück (siehe Schritt 9).
 
 ---