PocketBase as a standalone database server

The pocketbase driver no longer embeds PocketBase: Warp keeps its data as
PocketBase collections on a server of its own and reaches it only through
the REST API, the way the postgres driver reaches PostgreSQL.
database.connection_string is the server's URL, and Warp signs in as the
superuser in WARP_PB_SUPERUSER_EMAIL / WARP_PB_SUPERUSER_PASSWORD (or a
WARP_PB_SUPERUSER_FILE of the two).

Every SQL table is a superuser-only collection of the same name and
columns, created by warp migrate. Reads go through PocketBase's SQL
endpoint with the SQL drivers' queries, via a read-only database/sql
driver that inlines arguments, moves long ones into warp_params and pages
past 1000 rows. Writes are record operations in batch requests under one
write lock in the Warp process. Media is a protected file field in
warp_media, local or in the S3 bucket Warp writes into PocketBase's
settings. Search matches word prefixes with LIKE. The storage tests run
against an in-process PocketBase and pass as on SQLite.

Docker: the PocketBase stacks get a pocketbase service running
tajniak81/pocketbase-docker-root (WARP_PB_IMAGE), with a pb-data volume
and its admin UI on loopback; the AIO images run that PocketBase binary
as a process beside the homeserver, making up a superuser when none is
set. The .env examples, READMEs, docs and warp.yaml.example follow.

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

Docker/README.md

@@ -7,7 +7,7 @@ The homeserver (`warp`), the admin panel (`warp-admin`) and the web client
 | File | Database | Images |
 | --- | --- | --- |
 | `docker-compose.sqlite.yml` | SQLite, in the `warp-data` volume | built here |
-| `docker-compose.pocketbase.yml` | PocketBase, embedded in the homeserver, in `warp-data` | built here |
+| `docker-compose.pocketbase.yml` | PocketBase, a container of its own, in `pb-data` | built here |
 | `docker-compose.postgresql.yml` | PostgreSQL 17, its own container | built here |
 | `docker-compose.pocketbase.s3.yml` | PocketBase, media in an existing S3 bucket elsewhere | built here |
 | `docker-compose.pocketbase.seaweedfs.yml` | PocketBase, media in SeaweedFS, one container | built here |
@@ -26,16 +26,22 @@ Homeserver on `:8008`, admin panel on `:8009`, web client on `:8080`
 TLS-terminating reverse proxy in front before exposing them; see
 [docs/deployment.md](../docs/deployment.md).
 
-PocketBase is a database driver inside the homeserver, not a separate
-server, so the PocketBase files have no PocketBase container.
+The PocketBase files run PocketBase as a container of its own, from
+`tajniak81/pocketbase-docker-root` (`WARP_PB_IMAGE` picks another; any
+PocketBase 0.40 or later will do). Its data is in the `pb-data` volume, and
+the homeserver reaches it at `http://pocketbase:8070`, signed in as the
+superuser in `.env`. The image creates that superuser on its first start
+and leaves it alone after, so a new password is set in the admin UI first,
+at `http://localhost:8070/_/` on loopback, and in `.env` after.
 
 ## Media in S3
 
 The three `pocketbase.s3` and `pocketbase.seaweedfs` setups keep the
-PocketBase database in `/data/pb_data` and put media in an S3 bucket
+PocketBase database in `pb-data` and put media in an S3 bucket
 (`WARP_PB_S3_BUCKET`, default `warp`). Media already stored on the
 filesystem is not moved into the bucket when S3 is turned on, so start
-these on a fresh `warp-data` or copy the files across first.
+these on a fresh `pb-data` or copy the files across first. It is the
+PocketBase container that talks to the bucket.
 
 - **`docker-compose.pocketbase.s3.yml`**: a bucket that already exists
   elsewhere (AWS, MinIO, a SeaweedFS on another host). Set