Plugins: drop the plugins.json migration, and the volume it needed

The project has no public installs, so there is nothing to migrate from.
MigrateLegacyFile, the file-backed Store it read through, PLUGINS_FILE and
the legacy path threaded through the Server all go. What is left is one
store, PocketBase, and a plugins package that touches no filesystem at all.

That was the last thing keeping api_data alive, so the volume goes too. All
four compose files now declare exactly one volume, pb_data, and the
standalone API Server compose declares none - it talks to an external
PocketBase and has nothing of its own to keep. Backing up the stack is
backing up one path again.

Both images get simpler for it. The API Server image loses VOLUME /data and
the su-exec entrypoint that existed only to fix a mounted volume's
ownership, so it goes back to a plain USER app; its working directory is
now /app and holds nothing. The AIO image loses its second volume and
chowns only /pb/pb_data.

One consequence worth stating plainly, because it is a small regression
rather than a no-op. The panel's Settings -> PocketBase and Settings -> Web
App screens write .env in the working directory, which is now ephemeral. In
the multi-container stack that changes nothing: compose sets all five of
those keys as container environment, and loadDotEnv only applies a key that
is not already set, so the file could never win a restart there anyway. In
the AIO image it did win for POCKETBASE_ADMIN_EMAIL/_PASSWORD, which are
not in that container's environment - so a service account fixed from the
panel now lasts only until the container is recreated. Both READMEs say so.
Moving those two screens into the app_settings singleton would close it
properly; the PocketBase URL and credentials cannot follow, since they are
how the database is reached in the first place.

go build, go vet and go test ./... pass; the compose files parse and each
resolves to a single pb_data volume. Not verified: no Docker CLI here, so
neither image was built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

API Server/Dockerfile

@@ -23,54 +23,25 @@ RUN CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w" -o /out/api-ser
 FROM alpine:3.24
 
 # HTTPS calls to PocketBase need CA certificates; tzdata for correct timestamps.
-# su-exec lets the entrypoint fix /data ownership as root and then drop to app.
-RUN apk add --no-cache ca-certificates tzdata su-exec
+RUN apk add --no-cache ca-certificates tzdata
 
 # Run as an unprivileged user.
 RUN addgroup -S app && adduser -S -G app app
 
 COPY --from=build /out/api-server /usr/local/bin/api-server
 
-# The server writes .env relative to its working directory — the panel rewrites
-# it when a superadmin retargets the PocketBase connection — and reads a legacy
-# plugins.json from there once, to import it into the database. So the working
-# directory must be writable and persistent: hence /data, owned by the
-# unprivileged user and declared as a volume. A fresh named volume inherits this
-# ownership. (Plugin settings themselves live in PocketBase, not here.)
-RUN mkdir -p /data && chown app:app /data
-WORKDIR /data
-VOLUME /data
-
-# A fresh named volume inherits /data's ownership, but two common cases do not:
-# a host bind mount (API_DATA=/srv/... in docker-compose.prod.yml) arrives owned
-# by root, and so does a volume created by an image from before /data existed,
-# when the server ran with a root-owned working directory. In both cases the
-# unprivileged process cannot write .env, so retargeting PocketBase from the
-# panel silently fails to stick across a restart. The entrypoint therefore starts
-# as root purely to fix ownership, then drops to app.
-RUN cat > /entrypoint.sh <<'ENTRY'
-#!/bin/sh
-set -e
-if [ "$(id -u)" = "0" ]; then
-    mkdir -p /data
-    if [ "$(stat -c %U /data 2>/dev/null)" != "app" ]; then
-        echo "entrypoint: taking ownership of /data"
-        chown -R app:app /data
-    fi
-    exec su-exec app "$@"
-fi
-# Already unprivileged (docker run --user ...): nothing to drop, just run.
-exec "$@"
-ENTRY
-RUN chmod +x /entrypoint.sh
+# The server keeps no state on disk: plugin settings, like everything else, live
+# in PocketBase. The working directory is only where a .env would be read from
+# at startup if one were mounted, which is a local-development convenience — in
+# Docker every setting arrives as an environment variable. So no volume, and
+# nothing to make writable beyond the image layer itself.
+RUN mkdir -p /app && chown app:app /app
+WORKDIR /app
 
 # Config comes entirely from environment variables (see .env.example).
 # POCKETBASE_ADMIN_EMAIL / _PASSWORD are optional at startup: without them the
 # server still runs and a superadmin can configure the connection from the panel.
-# PLUGINS_FILE is only the one-time import path for a pre-PocketBase install;
-# the settings themselves live in the database.
-ENV API_ADDR=:8080 \
-    PLUGINS_FILE=/data/plugins.json
+ENV API_ADDR=:8080
 EXPOSE 8080
 
 # Liveness only: /healthz answers 200 as soon as the process is serving, and
@@ -79,6 +50,6 @@ EXPOSE 8080
 HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
     CMD wget -qO- http://127.0.0.1:8080/healthz >/dev/null 2>&1 || exit 1
 
-# The entrypoint drops to the unprivileged app user after fixing /data.
-ENTRYPOINT ["/entrypoint.sh"]
-CMD ["/usr/local/bin/api-server"]
+USER app
+
+ENTRYPOINT ["/usr/local/bin/api-server"]