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]>

docker-compose.yml

@@ -79,7 +79,16 @@ services:
         required: false
     expose:
       - "3000"
+    volumes:
+      # Persistiert hochgeladene Admin-Bilder/-Videos (Dockerfile legt
+      # /app/uploads bereits mit passendem Besitzer fuer den non-root
+      # "nextjs"-User an) ueber Container-Neustarts/-Redeploys hinweg — ohne
+      # dieses Volume waere jeder Upload nach dem naechsten "docker compose
+      # up" wieder weg.
+      - wabenhain_uploads_data:/app/uploads
     environment:
+      # Muss zum Volume-Mount oben passen — siehe .env.example.
+      UPLOAD_DIR: /app/uploads
       # DATABASE_URL kommt komplett aus .env — je nach DATABASE_PROVIDER
       # entweder die Postgres- ("db"-Service, Port 5432) oder die
       # MySQL-Verbindungszeichenkette ("db-mysql"-Service, Port 3306).
@@ -110,3 +119,4 @@ volumes:
   wabenhain_db_data:
   wabenhain_db_mysql_data:
   wabenhain_caddy_data:
+  wabenhain_uploads_data: