Plugins: the global layer moves into the database, beside the other two

The integration cascade stored its top layer differently from the two below
it: org (L2) and user (L3) plugin config lived in PocketBase, in a
pluginSettings field, while the global (L1) layer sat in a plugins.json
next to the binary. That split was accretion rather than design - the file
was the whole store in the v1 MVP, and the per-tenant layers were later
built on PocketBase and layered on top of it instead of replacing it.

It also cost something real. plugins.json was a second state store with
different durability from pb_data: its own volume, its own ownership, its
own backup. Losing pb_data is unmissable; losing api_data was silent, which
is how "every plugin comes back disabled after a redeploy" happened.

L1 now lives in the app_settings collection - one record keyed "global",
holding its settings in a pluginSettings field, the same mechanism and the
same field name the layers below use. The documents still differ in shape,
because only L1 carries enable state and the registration of external
plugins, but the storage is no longer a special case.

The Manager grows a Store seam (PocketBase in production, file for the
import, memory for tests) and, more importantly, a loaded gate. Settings in
a database mean the store can be unreachable at boot - a cold stack, or a
service account still to be set from the panel. That must not read as "no
plugins configured", or the first save would write emptiness over real
settings. So until a read succeeds the Manager stays unloaded, every
mutation is refused, /api/admin/plugins* answers 503, and a background
retry backs off to two minutes. The same gate covers a document that will
not parse: it is never replaced by one built from an empty map, which is a
stronger guarantee than the .corrupt backup it replaces.

Writing to a store also revealed a hole in the previous fix. Classifying a
save failure as errPersist was left to each Store, and a store that
returned a plain error would fall through to the "saved, but the plugin
failed to start" branch and be reported as a 200 - the same silent-success
bug through a different door. The Manager now classifies, whatever the
Store returns; a test pins it.

Upgrades are automatic: on the first boot that finds no settings in the
database, an existing plugins.json is imported and renamed to
plugins.json.migrated. The import is refused if the store is merely
unreachable, or if the file does not parse, so a stale or broken file can
never overwrite live settings. /data is still needed - the panel rewrites
.env there when it retargets PocketBase - but plugin settings no longer
depend on it.

21 tests in internal/plugins cover both stores, including the production
path against a fake PocketBase: create-then-update of the singleton,
round-trip across a restart, an outage that leaves settings intact, a
missing collection reading as not-ready rather than empty, and the import
running exactly once. go build, go vet and go test ./... pass. Schema
changes are mirrored into scripts/setup-pocketbase.mjs as that file
requires. Not verified: no Docker CLI here, so no image was built and the
bootstrap of app_settings against a real PocketBase is untested outside the
fake.

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

API Server/README.md

@@ -284,8 +284,9 @@ and then rebuild the Go binary, since `dist` is embedded.
 
 An extension system for integrating third-party services, managed by a
 superadmin. Two kinds share one contract: **built-in** (Go, compiled in) and
-**external** (any HTTP service, registered at runtime, **no rebuild**). State
-persists to `plugins.json`.
+**external** (any HTTP service, registered at runtime, **no rebuild**). Enable
+state and global config persist to PocketBase, in the `app_settings` singleton —
+the same place the per-org and per-user layers of the cascade live.
 
 See **[`internal/plugins/README.md`](internal/plugins/README.md)** for the full
 guide. Two built-in connectors ship today — **Toyota Connected** (`toyota`,
@@ -317,7 +318,7 @@ Copy `.env.example` to `.env` and fill in. Summary:
 | `CORS_ALLOW_ORIGINS` | `*` | comma-separated browser origins |
 | `WEBAPP_URL` | `http://localhost:8090` | probed by `/api/status` |
 | `AUTH_USERS_COLLECTION` | `users` | PocketBase auth collection |
-| `PLUGINS_FILE` | `plugins.json` | plugin state store |
+| `PLUGINS_FILE` | `plugins.json` | legacy plugin store, imported once then renamed |
 | `OCPP_REQUIRE_TLS` | `true` | reject chargers that did not connect over TLS |
 | `OCPP_PUBLIC_URL` | — | canonical `ws(s)://` base to point chargers at |
 | `PB_BOOTSTRAP` | `true` | run the on-boot schema create/reconcile |
@@ -326,10 +327,12 @@ Copy `.env.example` to `.env` and fill in. Summary:
 `PB_URL`, `PB_ADMIN_EMAIL`, `PB_ADMIN_PASSWORD`, `PORT` and `CORS_ORIGINS` are
 still honoured for older deployments; the modern names win when both are set.
 
-Two paths are resolved **relative to the working directory**: `PLUGINS_FILE` and
-the `.env` the panel rewrites when a superadmin retargets PocketBase. In Docker
-the working directory is `/data`, a volume, so both survive a container
-recreate — see [`Dockerfile`](Dockerfile) and [`../Docker`](../Docker).
+Two paths are resolved **relative to the working directory**: the `.env` the
+panel rewrites when a superadmin retargets PocketBase, and `PLUGINS_FILE` (read
+once, to import a pre-PocketBase plugin store). In Docker the working directory
+is `/data`, a volume, so the `.env` survives a container recreate — see
+[`Dockerfile`](Dockerfile) and [`../Docker`](../Docker). Plugin settings no
+longer depend on that volume: they live in the database with everything else.
 
 `CORS_ALLOW_ORIGINS` only matters for **browser** clients (the web app). Native
 mobile apps are not subject to CORS.