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.

docs/ci-release-pipeline.md

@@ -105,14 +105,24 @@ the workflow.
    volume), or run the runner in host mode. The dind sidecar is the safer of the two — mounting the
    host socket into job containers gives any workflow root on the runner host.
 
-   **Reachability is a separate question from availability, and it bit us.** Mounting the host
-   socket into a containerised job gives it a working daemon, and `pytest tests/` still fails with
-   `Service 'pytest_databases_postgres' failed to come online`: the container starts fine, but its
-   published port lands on the *host's* network namespace while the test process looks for it on
-   the job container's loopback. `pytest_databases/docker/__init__.py` picks the address from
-   `DOCKER_HOST` — `127.0.0.1` when it is unset or `unix://`, otherwise the hostname out of
-   `tcp://host:port`. So a TCP `DOCKER_HOST` is what makes the sibling container addressable, and
-   the value must include the port or it raises rather than falling back.
+   **Reachability is a separate question from availability, and it bit us.** A containerised job
+   with a working daemon still fails `pytest tests/` with
+   `Service 'pytest_databases_postgres' failed to come online`: the database container starts
+   fine, but its published port lands on the daemon's network namespace while the test process
+   looks for it on the job container's loopback.
+
+   Two variables control two different things, and both must be set:
+
+   | Variable | Decides | Read by |
+   | --- | --- | --- |
+   | `DOCKER_HOST` | which daemon the container is created on | `_service.py` `get_docker_host()` |
+   | `POSTGRES_HOST` | the address the test then connects to | `docker/postgres.py` `postgres_host`, default `127.0.0.1` |
+
+   Setting only `DOCKER_HOST` is not enough — `DockerService.run()` takes `container_host` as a
+   plain argument defaulting to `127.0.0.1`, and the postgres fixture fills it from
+   `POSTGRES_HOST`. (There *is* a `DOCKER_HOST`-parsing helper in `pytest_databases`, but it is
+   `_get_docker_ip()` on the docker-compose class in `docker/__init__.py` and no part of this
+   path uses it. Do not be misled by it, as I was.)
 
    Until the runner grows its own sidecar, `ci.yml`'s backend job carries a `docker:dind` service
    of its own with `DOCKER_HOST: tcp://docker:2375`. That needs the runner to permit