feat(betrieb): native Installation, Proxmox-Einzeiler und Abnahme (#37)

Zwei Wege in den Betrieb, beide so weit gefahren, wie es hier moeglich war.

deploy/install.sh richtet Debian 13 in neun Schritten ein: PostgreSQL 17 hoert
nur am Unix-Socket, der Dienstnutzer hat kein Login, die Geheimnisse entstehen
im Zielsystem und liegen 0600 bei root. Die Umgebungsdatei wird nie
ueberschrieben -- auch nicht beim Aktualisieren, sonst enden alle Sitzungen und
die verschluesselten Bind-Passwoerter waeren unlesbar.

deploy/proxmox/laufzettel.sh legt den Container an und ruft install.sh darin
auf. Der pct-Teil ist ungetestet, weil kein PVE-Host zur Verfuegung stand; die
Gegenprobe steht als Pruefliste in docs/betrieb/proxmox.md, das Folge-Issue ist
Nummer 38.

Die Abnahme gegen alle 61 Kriterien hat drei Zusagen ohne Deckung gefunden, alle
behoben: der Healthcheck des Webdienstes konnte nie bestehen (busybox loest
localhost nach ::1 auf, Next lauscht nur auf IPv4), die CI-Pipeline konnte in
keinem Job gruen werden (kein LDAP-Dienst, kein gestarteter Server, kein
shellcheck), und der README nannte fuer die Entwicklungsdatenbank den falschen
Port.

Closes #19

docs/issues/025-gesundheit-fehlermeldung.md

@@ -0,0 +1,35 @@
+# #025 Healthcheck gibt die rohe Datenbankfehlermeldung heraus
+
+**Status:** offen
+**Im Tracker:** [#39](https://git.wilde-server.de/florian.wilde/Laufzettel/issues/39)
+**Meilenstein:** v0.2.0
+**Labels:** phase-2, backend
+**Geschätzt:** 1 h   **Tatsächlich:** –
+
+## Ziel
+
+`src/app/api/gesundheit/route.ts` antwortet im Fehlerfall mit
+
+```json
+{ "status": "fehler", "meldung": "<fehler.message>" }
+```
+
+Der Pfad ist absichtlich ohne Anmeldung erreichbar — er steht in der Allowlist des Proxys, und
+`tests/sicherheitsrichtlinie.test.ts` hält das fest. Eine Fehlermeldung von Prisma oder `pg` nennt
+typischerweise Host, Port, Benutzername und Datenbanknamen. Das ist für einen öffentlich erreichbaren
+Endpunkt zu viel: er soll sagen, **ob** es geht, nicht warum nicht.
+
+Aufgefallen beim Abnahme-Review zu [#019](019-betrieb-release.md).
+
+## Aufgaben
+
+- [ ] Nach außen nur `{ "status": "fehler" }` mit Status 503
+- [ ] Die Begründung serverseitig protokollieren, damit sie beim Suchen nicht fehlt
+- [ ] Prüfen, ob `docs/betrieb/` irgendwo die Meldung als Diagnosehilfe nennt — dann auf das Log
+      verweisen
+
+## Akzeptanzkriterien
+
+- [ ] Test: bei nicht erreichbarer Datenbank enthält die Antwort weder Host noch Port noch
+      Benutzernamen
+- [ ] Test: der Statuscode bleibt 503, damit Docker und der Reverse Proxy weiter richtig entscheiden