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>

Docker/.env.prod.example

@@ -61,9 +61,7 @@ API_BIND=127.0.0.1
 # --- Storage -----------------------------------------------------------------
 # Defaults are Docker-managed named volumes. To store either on a host path
 # instead, set it to an absolute path, e.g. PB_DATA=/srv/drivervault/pb_data.
-# PB_DATA  — the PocketBase database and uploads.
-# API_DATA — the .env the API Server panel writes back (plugin settings are in
-# the database, under PB_DATA)
-#            when a superadmin retargets the PocketBase connection.
+# PB_DATA — the PocketBase database and uploads. It is the only volume in the
+# stack: the API Server keeps no state on disk, so everything it owns (plugin
+# settings included) is backed up by backing up this one path.
 PB_DATA=pb_data
-API_DATA=api_data

Docker/README.md

@@ -64,28 +64,19 @@ schema reconcile itself.
 
 | Volume | Holds |
 |---|---|
-| `pb_data` | the PocketBase SQLite database and uploaded files |
-| `api_data` | the `.env` the API Server panel rewrites when a superadmin retargets the PocketBase connection (plugin settings live in `pb_data`, with everything else) |
+| `pb_data` | the PocketBase SQLite database and uploaded files — everything that persists |
 
-Both default to Docker-managed named volumes. In the prod file, set `PB_DATA` /
-`API_DATA` to absolute host paths for bind mounts instead.
+One volume, because the API Server keeps no state on disk. Plugin enable-state
+and global config live in the database like the rest of the settings, so backing
+up `pb_data` backs up the whole stack. It defaults to a Docker-managed named
+volume; set `PB_DATA` to an absolute host path in the prod file for a bind mount
+instead. PocketBase runs as root, so a root-owned host directory is fine.
 
-> The API Server serves as the unprivileged `app` user, so `/data` has to be
-> writable by it. Its entrypoint arranges that itself: it starts as root, takes
-> ownership of `/data` if `app` does not already hold it, then drops privileges.
-> So a **bind mount** to a root-owned host path needs no manual `chown`, and
-> neither does a **named volume** left over from an image that ran as root. The
-> one case it cannot fix is a container forced to another user (`user:` in
-> compose, `docker run --user`), where the entrypoint has no privileges to
-> `chown` with — prepare the host directory yourself there. PocketBase runs as
-> root, so `PB_DATA` is unaffected either way.
-
-Plugin enable-state and global config used to live in a `plugins.json` on this
-volume, which made them the one piece of configuration a lost volume could erase
-without anyone noticing. They are now in PocketBase, backed up with `pb_data`
-like everything else. An existing `plugins.json` is imported automatically on the
-first boot after the upgrade and renamed to `plugins.json.migrated`; keep the
-volume mounted for that boot.
+> One thing does **not** persist: the API Server panel's *Settings → PocketBase*
+> and *Settings → Web App* screens apply immediately but only for the life of the
+> container. Set `POCKETBASE_URL`, `PB_ADMIN_EMAIL` / `PB_ADMIN_PASSWORD`,
+> `WEBAPP_URL` and `CORS_ALLOW_ORIGINS` in `.env` to change them permanently —
+> in this stack the compose environment wins over anything the panel writes.
 
 ## Charger control (OCPP)
 

Docker/docker-compose.prod.yml

@@ -81,11 +81,8 @@ services:
       # network). Set API_BIND=0.0.0.0 to expose the API panel — and the
       # /ocpp/{serial} endpoint chargers dial into — on the network.
       - "${API_BIND:-127.0.0.1}:${API_PORT:-8080}:8080"
-    volumes:
-      # The .env the panel writes back when a superadmin retargets PocketBase —
-      # see the API Server Dockerfile. Plugin settings live in the database, so
-      # they no longer depend on this volume.
-      - "${API_DATA:-api_data}:/data"
+    # No volume: the API Server keeps no state on disk — every setting it owns,
+    # plugin settings included, lives in PocketBase under PB_DATA.
     healthcheck:
       # Declared here rather than relying only on the image's HEALTHCHECK, so the
       # depends_on gate below still works against an older pulled image.
@@ -119,4 +116,3 @@ services:
 
 volumes:
   pb_data:
-  api_data:

Docker/docker-compose.yml

@@ -74,11 +74,8 @@ services:
       # App reaches it over the internal network, not this host port. Chargers
       # dialling /ocpp/{serial} also arrive here.
       - "${API_PORT:-8080}:8080"
-    volumes:
-      # The .env the panel writes back when a superadmin retargets PocketBase —
-      # see the API Server Dockerfile. Plugin settings live in the database, so
-      # they no longer depend on this volume.
-      - api_data:/data
+    # No volume: the API Server keeps no state on disk — every setting it owns,
+    # plugin settings included, lives in PocketBase under pb_data.
     healthcheck:
       # Declared here rather than relying only on the image's HEALTHCHECK, so the
       # depends_on gate below still works against an older pulled image.
@@ -116,4 +113,3 @@ services:
 
 volumes:
   pb_data:
-  api_data: