fix: Admin-Uploads auf dem Live-Server (Berechtigung, Persistenz, Body-Size-Limit)

Uploads (Bilder + Hero-Video) schlugen live fehl, lokal aber nicht: der
Container laeuft als non-root "nextjs", /app/uploads existierte nirgends
vorbereitet und gehoert root -> mkdir() scheiterte mit EACCES, unbehandelt
als HTML-500 statt JSON, der Client zeigte nur einen haengenden
"wird hochgeladen"-Zustand ohne Fehlermeldung.

- Dockerfile legt /app/uploads jetzt vor dem User-Wechsel an und
  uebereignet es dem nextjs-Nutzer
- docker-compose.yml persistiert Uploads jetzt ueber ein eigenes Volume
  (vorher gingen sie bei jedem Redeploy verloren) und setzt UPLOAD_DIR
  explizit
- Beide Upload-Routen fangen Dateisystemfehler jetzt ab und liefern eine
  echte JSON-Fehlermeldung statt eine unbehandelte Exception
- k8s-Manifeste vorsorglich mitgefixt (fsGroup fuer den Volume-Mount,
  Ingress-Body-Size-Limit) fuer den Fall eines spaeteren
  Kubernetes-Wechsels

Co-Authored-By: Claude Sonnet 5 <[email protected]>

k8s/06-ingress.yaml

@@ -18,6 +18,15 @@ metadata:
     # oder TLS auf andere Weise terminieren.
     cert-manager.io/cluster-issuer: letsencrypt-prod
     nginx.ingress.kubernetes.io/ssl-redirect: "true"
+    # ingress-nginx laesst ohne diese Annotation standardmaessig nur 1 MB pro
+    # Request durch — weit unter dem Bild- (8 MB, lib/uploads.ts
+    # MAX_UPLOAD_BYTES) und erst recht dem Video-Limit (40 MB, lib/uploads.ts
+    # MAX_UPLOAD_VIDEO_BYTES) der Admin-Uploads. Ohne diese Zeile bricht
+    # nginx jeden Upload jenseits von 1 MB vor der App ab (Verbindungsabbruch
+    # ohne verwertbare Fehlermeldung im Browser) — 45m deckt das groessere der
+    # beiden Limits (40 MB) plus etwas Spielraum fuer den multipart/form-data-
+    # Overhead ab.
+    nginx.ingress.kubernetes.io/proxy-body-size: "45m"
 spec:
   ingressClassName: nginx
   tls: