fix(gesundheit): Fehlergrund nicht mehr unangemeldet herausgeben

/api/gesundheit steht in der Allowlist des Proxys, damit ein Healthcheck kein
Cookie braucht. Eine Meldung von Prisma oder pg nennt aber Host, Port,
Benutzernamen und Datenbanknamen -- fuer einen Pfad, der ohne Anmeldung
antwortet, ist das zu viel.

Nach aussen bleibt {"status":"fehler"} mit 503, damit Docker und der Reverse
Proxy weiter richtig entscheiden. Die Begruendung geht ins Protokoll des
Prozesses, nach demselben Muster wie in src/server/actions/verzeichnis.ts.

Fuenf Tests, darunter einer fuer die andere Haelfte der Zusage: dass die
Begruendung wirklich geschrieben und nicht verschluckt wird. Gegenprobe
gefahren -- mit der alten Fassung werden drei davon rot.

Closes #39

docs/betrieb/inbetriebnahme.md

@@ -249,7 +249,7 @@ Datei nicht neu. Änderungen an `APP_VERSION` oder `GIT_SHA` sind Build-Argument
 |---|---|
 | `APP_SECRET fehlt in der .env` beim `up` | Genau das. Der Stand bricht absichtlich ab, statt mit einem Standardwert zu starten. Gilt ebenso für `APP_URL` und `POSTGRES_PASSWORD`. |
 | `web` startet nicht, `migrate` steht auf `exited (1)` | `docker compose logs migrate`. Meist erreicht die Migration die Datenbank nicht — oder du hast `POSTGRES_PASSWORD` nach dem ersten Start geändert. Das Passwort steckt dann noch im Volume. |
-| `/api/gesundheit` antwortet mit 503 | Die Anwendung läuft, die Datenbank antwortet nicht. `docker compose ps` — ist `postgres` gesund? |
+| `/api/gesundheit` antwortet mit 503 | Die Anwendung läuft, die Datenbank antwortet nicht. `docker compose ps` — ist `postgres` gesund? Die Antwort nennt absichtlich keinen Grund, weil der Pfad ohne Anmeldung erreichbar ist; der Grund steht in `docker compose logs web`. |
 | Der Seed bricht mittendrin ab | Bis zur Abnahme von #019 fehlte dem Einmal-Dienst `APP_SECRET`, und das Bind-Passwort der Beispiel-Verzeichnisquelle ließ sich nicht verschlüsseln — abgebrochen wurde erst, nachdem die Vorlagen schon standen. Steht dein `docker-compose.yml` auf dem aktuellen Stand, ist das behoben; ein erneuter Lauf holt den Rest nach. |
 | Nach dem Login wieder auf der Anmeldeseite | Das Cookie ist `Secure`, die Verbindung aber `http`. `APP_URL` auf `https://…` setzen und HTTPS über den Proxy anbieten. |
 | Die QR-Codes zeigen auf `localhost:3000` | `APP_URL` ist nicht oder falsch gesetzt. Die Oberfläche warnt unter **Admin** und in der Etikettenansicht davor. Aufkleber, die so gedruckt wurden, sind wertlos — bevor du weiterdruckst, `APP_URL` richtigstellen und `docker compose up -d`. |

docs/betrieb/reverse-proxy.md

@@ -203,6 +203,11 @@ schlimmsten Fall, macht den Unterpfad aber nicht betriebsfähig.
 antwortet `{"status":"ok"}` oder mit Status 503. Das ist der richtige Pfad für die Überwachung des
 Proxys; `/` leitet ohne Cookie auf die Anmeldeseite um und sagt nichts über den Zustand.
 
+Im Fehlerfall sagt er nur `{"status":"fehler"}` und **nicht, warum** — der Pfad ist ohne Anmeldung
+erreichbar, und eine Datenbankmeldung nennt Host, Port, Benutzernamen und Datenbanknamen. Die
+Begründung steht im Protokoll des Prozesses: `docker compose logs web` beziehungsweise
+`journalctl -u laufzettel -n 50`.
+
 **Die Kamera braucht HTTPS.** Der QR-Scanner in der Anwendung benutzt die Kamera des Geräts, und
 Browser geben sie nur über eine gesicherte Verbindung frei (`localhost` ausgenommen). Ohne TLS
 scannt am Handy niemand — das ist der praktische Grund, warum der Proxy nicht optional ist.

docs/issues/025-gesundheit-fehlermeldung.md

@@ -1,10 +1,10 @@
 # #025 Healthcheck gibt die rohe Datenbankfehlermeldung heraus
 
-**Status:** offen
+**Status:** erledigt
 **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:** –
+**Geschätzt:** 1 h   **Tatsächlich:** 25 min
 
 ## Ziel
 
@@ -23,13 +23,13 @@ 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
+- [x] Nach außen nur `{ "status": "fehler" }` mit Status 503
+- [x] Die Begründung serverseitig protokollieren, damit sie beim Suchen nicht fehlt
+- [x] 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
+- [x] 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
+- [x] Test: der Statuscode bleibt 503, damit Docker und der Reverse Proxy weiter richtig entscheiden