fix(docker): entrypoint chowns /work/data so H2 can create on fresh volume

Cuando el volumen named 'shot-crafter-data' es nuevo, Docker lo monta
con owner root:root. La aplicacion corre como UID 1001 y no puede
escribir -> H2 falla al crear shots.mv.db -> BootstrapAdmin no crea
el admin -> no se puede login.

Quitar 'USER 1001' del Dockerfile, agregar entrypoint.sh que:
1. chown -R 1001:1001 /work/data (la app va a poder escribir)
2. chmod 0755 /work
3. setpriv --reuid=1001 --regid=1001 --init-groups -- /work/application
   (drop a no-root antes del exec)

Resultado: el contenedor arranca como root el primer instante, hace
el fix de permisos una sola vez, y desde ese momento la app corre
como 1001. Docker defaults USER a root cuando no hay directiva USER.

Dockerfile

@@ -7,10 +7,11 @@ RUN apt-get update \
  && chown 1001:1001 /work
 WORKDIR /work/
 COPY --chown=1001:1001 build-output/*-runner /work/application
-RUN chmod 775 /work /work/application \
+COPY entrypoint.sh /entrypoint.sh
+RUN chmod 0755 /entrypoint.sh \
+ && chmod 775 /work /work/application \
  && echo "securerandom.source=file:/dev/urandom" >> /work/application
 
 EXPOSE 8080
-USER 1001
 
-ENTRYPOINT ["./application"]
+ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+set -eu
+
+# Arranca como root (USER no está fijado en el Dockerfile, así Docker usa root).
+# En el primer arranque, /work/data es el punto de montaje del volumen named
+# shot-crafter-data: Docker lo crea con owner root:root, lo que impide al UID
+# 1001 (con el que corre la app) escribir. Tomamos root brevemente para
+# arreglar los permisos, y después setpriv baja al UID 1001 para la app.
+mkdir -p /work/data
+chown -R 1001:1001 /work/data || {
+  echo "WARNING: failed to chown /work/data (root filesystem?); app may fail to start" >&2
+}
+chmod 0755 /work
+
+exec setpriv --reuid=1001 --regid=1001 --init-groups -- /work/application "$@"