fix: Health-Endpunkte trennen Liveness von Readiness

Readiness- und Liveness-Probe zeigten beide auf "/" — eine
force-dynamic-Seite samt Datenbankabfragen und vollem React-Rendering, alle
10 bzw. 30 Sekunden.

Der teure Teil ist dabei nicht das eigentliche Problem. Entscheidend ist,
dass damit auch die LIVENESS-Probe an der Datenbank haengt: faellt die DB
voruebergehend aus, wertet Kubernetes den Container als tot und startet ihn
neu — woraufhin der neue Container laut Dockerfile-CMD zuerst
"prisma migrate deploy" und "prisma db seed" gegen genau die gestoerte
Datenbank faehrt. Aus einer voruebergehenden Stoerung wird so eine
Neustart-Schleife.

Jetzt zwei Endpunkte mit klar getrennter Aufgabe:

- /api/health       — nur "Prozess antwortet", ohne Datenbankzugriff.
                      Liveness-Probe.
- /api/health/ready — zusaetzlich "SELECT 1" gegen die Datenbank, sonst 503.
                      Readiness-Probe und Docker-Healthcheck.

Faellt die Readiness-Probe aus, nimmt Kubernetes den Pod nur aus dem
Load-Balancing und startet ihn nicht neu — genau das richtige Verhalten.
"SELECT 1" laeuft unveraendert auf PostgreSQL und MySQL/MariaDB und
beruehrt keine Tabelle, ist also unabhaengig vom Migrationsstand. Die
Fehlerdetails gehen nur ins Server-Log, nicht in die oeffentliche Antwort.

docker-compose.yml bekommt denselben Readiness-Endpunkt als Healthcheck,
mit start_period fuer den Migrations-/Seed-Lauf vor dem Serverstart.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

k8s/05-app-deployment.yaml

@@ -60,15 +60,26 @@ spec:
             # (fehlende Volume-Referenz).
             - name: uploads
               mountPath: /app/uploads
+          # Prueft die Datenbank mit (siehe app/api/health/ready/route.ts).
+          # Schlaegt sie fehl, nimmt Kubernetes den Pod nur aus dem
+          # Load-Balancing, startet ihn aber nicht neu.
           readinessProbe:
             httpGet:
-              path: /
+              path: /api/health/ready
               port: 3000
             initialDelaySeconds: 10
             periodSeconds: 10
+          # Bewusst der DB-FREIE Endpunkt (siehe app/api/health/route.ts):
+          # eine Liveness-Probe an der Datenbank wuerde aus einer
+          # voruebergehenden DB-Stoerung eine Neustart-Schleife machen, weil
+          # der neu startende Container laut Dockerfile-CMD zuerst
+          # "prisma migrate deploy" gegen dieselbe gestoerte Datenbank faehrt.
+          # Beide Probes zeigten vorher auf "/" — also auf eine
+          # force-dynamic-Seite mit DB-Abfragen und vollem React-Rendering
+          # alle 10 bzw. 30 Sekunden.
           livenessProbe:
             httpGet:
-              path: /
+              path: /api/health
               port: 3000
             # initialDelaySeconds/failureThreshold grosszuegiger als sonst
             # ueblich: der Container migriert/seedet die DB selbst vor dem