fix: tell the tests where the database actually is

DOCKER_HOST only decides which daemon creates the container; the address the
test dials comes from POSTGRES_HOST, which defaults to the job container's own
loopback. Setting one without the other still times out.

.gitea/workflows/ci.yml

@@ -19,14 +19,19 @@ jobs:
   backend:
     runs-on: ubuntu-latest
 
-    # pytest-databases starts PostgreSQL in a container and then connects to it. Which address
-    # it connects to is decided by DOCKER_HOST: unset or unix:// means 127.0.0.1, which is wrong
-    # here because the job is itself a container and the database is a sibling, published on
-    # another network namespace. Pointing at a dind service instead makes pytest-databases
-    # resolve the host to `docker`, where the port really is.
+    # pytest-databases starts PostgreSQL in a container and then connects to it, and those are
+    # two different addresses that have to be set separately:
     #
-    # If the runner is ever configured with its own dind sidecar, delete this block and the
-    # DOCKER_HOST below: every job gets a daemon then, including the ones in release.yml.
+    #   DOCKER_HOST    which daemon to create the container on  (_service.py get_docker_host)
+    #   POSTGRES_HOST  where the test then connects             (docker/postgres.py, default
+    #                  127.0.0.1 -- the job container's own loopback, where nothing listens,
+    #                  because the database is a sibling container on another namespace)
+    #
+    # Setting only the first leaves the tests dialling 127.0.0.1 and timing out with
+    # "Service 'pytest_databases_postgres' failed to come online".
+    #
+    # If the runner is ever given its own dind sidecar, drop this services block and keep the
+    # two env vars pointed at whatever host it exposes.
     services:
       docker:
         image: docker:27-dind
@@ -36,6 +41,7 @@ jobs:
 
     env:
       DOCKER_HOST: tcp://docker:2375
+      POSTGRES_HOST: docker
 
     defaults:
       run: