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