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>

README.md

@@ -22,9 +22,9 @@ carries its thread summary, latest edit and references in
 through the federation hierarchy endpoint, and `room_summary`. `/search`
 runs on SQLite's FTS5 or PostgreSQL's `tsvector`, bounded to what each user
 may see, with context, profiles, state and grouping. The PocketBase driver
-is real: the SQLite schema inside an embedded PocketBase app, with media in
-its filesystem — local or S3 — and it passes the same storage tests as
-SQLite. OpenTelemetry tracing follows a request from the client through
+keeps Warp's data as collections on a PocketBase server of its own, through
+its REST API, with media in its storage — local or S3 — and it passes the
+same storage tests as SQLite. OpenTelemetry tracing follows a request from the client through
 federation, push and application service calls; `/metrics` gains event,
 sync and database pool metrics, with a Grafana dashboard over them. There
 is a Compose setup, a Helm chart and a load tester (`warp-loadtest`), and