fix: give the backend CI job a docker daemon it can address

The runner has docker, so the database container started; the job just could
not reach it. pytest-databases takes the address from DOCKER_HOST, and unset
means 127.0.0.1 -- the job container's loopback, not the namespace the sibling
published on. A dind service makes it resolve to a host that answers.

.gitea/workflows/ci.yml

@@ -19,6 +19,24 @@ 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.
+    #
+    # 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.
+    services:
+      docker:
+        image: docker:27-dind
+        options: --privileged
+        env:
+          DOCKER_TLS_CERTDIR: ''
+
+    env:
+      DOCKER_HOST: tcp://docker:2375
+
     defaults:
       run:
         working-directory: backend
@@ -42,8 +60,6 @@ jobs:
       - name: Lint
         run: uv run ruff check src/ tests/
 
-      # pytest-databases starts a throwaway PostgreSQL container, so this needs a working
-      # Docker daemon on the runner — the same requirement the release workflow has.
       - name: Tests
         run: uv run pytest tests/ -q