fix(docker): move postgres data to a named volume, off the WSL2 bind mount

The ./data/postgres bind mount hit 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, which took the whole
database down after an unclean shutdown. Switches to a Docker-managed
named volume (bellsystems-postgres-data) that lives inside the WSL2
VM's own filesystem instead. The old bind-mounted data is left in
place at ./data/postgres/ as an untouched backup — that folder was
too wedged by the same bug to even rename, so it's abandoned rather
than deleted.

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

docker-compose.yml

@@ -50,7 +50,7 @@ services:
       POSTGRES_USER: ${POSTGRES_USER}
       POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
     volumes:
-      - ./data/postgres:/var/lib/postgresql/data
+      - postgres-data:/var/lib/postgresql/data
     networks:
       - internal
     healthcheck:
@@ -62,3 +62,17 @@ services:
 networks:
   internal:
     driver: bridge
+
+volumes:
+  # Docker-managed volume (lives inside the WSL2 VM's own filesystem) instead
+  # of a ./data/postgres bind mount onto the Windows filesystem. The bind
+  # mount hit 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, which took the whole database down after an unclean shutdown.
+  # Migrated 2026-09-04; the old bind-mounted data is untouched at
+  # ./data/postgres/ as a backup (that folder itself was too wedged by the
+  # same bug to even rename — leave it alone; it's not used anymore).
+  postgres-data:
+    name: bellsystems-postgres-data
+    external: true