fix(docker): keep server Postgres on ./data/postgres, move Windows volume to an override

751cac7 switched the base compose file to an external named volume
(bellsystems-postgres-data) to dodge a WSL2/Docker Desktop bind-mount bug.
That volume only exists on the Windows dev machine: on the VPS, where the
push auto-deploys via deploy-host.sh, `docker compose up` would fail on the
missing external volume (or, if created, start Postgres on an empty
database while the real data sat unused in ./data/postgres).

The base file goes back to the ./data/postgres bind mount the server has
always used (Linux has no such bug). The named volume now lives in
docker-compose.override.yml, which Compose loads automatically, is
gitignored, and is created from docker-compose.override.example.yml on
Windows machines only.

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

docker-compose.override.example.yml

@@ -0,0 +1,18 @@
+# Windows / Docker Desktop dev machines only — copy to docker-compose.override.yml
+# (gitignored; Docker Compose loads it automatically). The server does NOT use this.
+#
+# Why: a ./data/postgres bind mount onto the Windows filesystem hits a
+# WSL2/Docker Desktop bug where the 9p/virtiofs bridge reports normal
+# postgres:postgres 0600 ownership but the kernel still refuses the postgres
+# user's own open() calls for write — silent on read, fatal on any WAL write.
+# A Docker-managed named volume lives inside the WSL2 VM's own filesystem and
+# avoids it. Create it once with: docker volume create bellsystems-postgres-data
+services:
+  postgres:
+    volumes:
+      - postgres-data:/var/lib/postgresql/data
+
+volumes:
+  postgres-data:
+    name: bellsystems-postgres-data
+    external: true