Fix CI/CD deploy targeting the wrong compose project

COMPOSE_PROJECT_NAME was "ruvdstests" but the live stack was actually
deployed under "ruvdstest" (no trailing s) — Compose treated it as an
unrelated project and spun up a whole second stack from scratch,
colliding with the real one's host port and aborting mid-deploy
instead of updating the running containers in place.

.gitea/workflows/ci-cd.yml

@@ -9,7 +9,11 @@ on:
 # Pinned so every run targets the same project regardless of the runner's
 # checkout path — otherwise `docker compose` would derive the project name
 # from the checkout directory, potentially spinning up a second stack and
-# losing the `pgdata` volume instead of updating the running one.
+# losing the `pgdata` volume instead of updating the running one. Must be
+# `ruvdstest` (no trailing "s") to match the project name the live stack was
+# actually deployed under — a one-letter mismatch here previously made
+# Compose treat it as an unrelated project and spin up a whole second stack
+# from scratch instead of recognizing and updating the running containers.
 #
 # JWT_SECRET/POSTGRES_PASSWORD come from Gitea's own Actions secrets store
 # rather than the `.env` file DEPLOY.md has the human create in
@@ -20,7 +24,7 @@ on:
 # COMPOSE_PROJECT_NAME above), and a different POSTGRES_PASSWORD than what
 # the live `pgdata` volume was initialized with breaks the DB connection.
 env:
-  COMPOSE_PROJECT_NAME: ruvdstests
+  COMPOSE_PROJECT_NAME: ruvdstest
   JWT_SECRET: ${{ secrets.JWT_SECRET }}
   POSTGRES_PASSWORD: ${{ secrets.POSTGRES_PASSWORD }}