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/05-app-deployment.yaml

@@ -27,6 +27,17 @@ spec:
       labels:
         app: wabenhain-app
     spec:
+      # fsGroup=1001 muss zur "nodejs"-Gruppe (gid 1001) passen, die das
+      # Dockerfile fuer den non-root "nextjs"-Laufzeitbenutzer anlegt: ohne
+      # dieses Feld mountet Kubernetes das "uploads"-Volume (egal ob emptyDir
+      # oder ein echtes PVC) mit root:root-Besitz — das ueberschreibt den im
+      # Image bereits per chown gesetzten Besitzer von /app/uploads
+      # vollstaendig, und der nicht-root laufende Container koennte trotzdem
+      # keine Datei dort anlegen (EACCES bei jedem Admin-Upload). fsGroup
+      # sorgt dafuer, dass Kubernetes JEDES gemountete Volume zusaetzlich der
+      # Gruppe 1001 zuordnet und gruppen-schreibbar macht.
+      securityContext:
+        fsGroup: 1001
       containers:
         - name: app
           image: git.encry.de/nick.rosenloecher/wabenhain:latest

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: