fix(staging): unify matchmaking-v2 network topology + redact Apify token

Root cause: the VPS ran two Compose projects from the same file — api under
-p matchmaking-v2-staging, postgres/redis under -p matchmaking-v2 — creating
two disjoint <project>_default bridges. Every dependency hostname (postgres,
redis) was NXDOMAIN from the api container, so feed store init, pool_load,
save_feed, and RedisStreamWorker all failed with [Errno -2].

Fix: standardize on a single project (matchmaking-v2) for all three services
with an external shared bridge (matchmaking-v2_default) and inline DB/Redis
host pinning. The deploy script (sync-staging.sh) now brings up all three
services, pre-creates the external network, and has a public_health_url case.

Apify: moved the token from query params (4 sites) to an Authorization header
so no request URL can leak it. All raise_for_status() paths now raise
token-free _ApifyHTTPError. The live 403 (platform-feature-disabled: monthly
usage cap exceeded) is an external blocker — no code fix.

Tests: 15 focused regression tests covering network topology, volume config,
deploy-script alignment, and Apify token redaction (with call-counters).

docker-compose.staging.yml

@@ -0,0 +1,74 @@
+# ── Matchmaking v2 staging stack ────────────────────────────────────────────
+# Project name is `matchmaking-v2` (matches scripts/sync-staging.sh compose_project
+# and the live volume/network names). All three services deploy together so they
+# share one Compose default bridge and the depends_on graph holds:
+#
+#   docker compose -p matchmaking-v2 -f docker-compose.staging.yml up -d
+#
+# The prior VPS split (api under `-p matchmaking-v2-staging`, postgres/redis under
+# `-p matchmaking-v2`) created two disjoint `<project>_default` bridges → every
+# dependency hostname was NXDOMAIN from the api. Standardizing on `matchmaking-v2`
+# for all services fixes that at the root and matches the deploy automation.
+#
+# The Postgres data volume stays project-scoped (matchmaking-v2_matchmaking_pgdata) —
+# the existing live volume with its PG cluster is reused as-is, no migration or rename.
+#
+# External network — pre-created by the deploy guard (sync-staging.sh compose_networks)
+# or manually (guard is a no-op if it already exists):
+#   docker network create matchmaking-v2_default 2>/dev/null || true
+services:
+  api:
+    build: .
+    container_name: growqr-matchmaking-api
+    ports:
+      - "127.0.0.1:18006:8000"
+    env_file:
+      - .env.staging
+    # Pin DB/Redis hosts to the compose service names so connectivity doesn't
+    # hinge on .env.staging (git-ignored). Credentials mirror the postgres
+    # service below — no new secret introduced.
+    environment:
+      DATABASE_URL: postgresql+asyncpg://matchmaking:matchmaking@postgres:5432/matchmaking
+      REDIS_URL: redis://redis:6379/0
+    depends_on:
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_started
+    command: uvicorn app.main:app --host 0.0.0.0 --port 8000
+    restart: unless-stopped
+
+  postgres:
+    image: postgres:16-alpine
+    container_name: growqr-matchmaking-postgres
+    environment:
+      POSTGRES_USER: matchmaking
+      POSTGRES_PASSWORD: matchmaking
+      POSTGRES_DB: matchmaking
+    ports:
+      - "127.0.0.1:15446:5432"
+    volumes:
+      - matchmaking_pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U matchmaking -d matchmaking"]
+      interval: 5s
+      timeout: 3s
+      retries: 20
+    restart: unless-stopped
+
+  redis:
+    image: redis:7-alpine
+    container_name: growqr-matchmaking-redis
+    restart: unless-stopped
+
+# External bridge — pre-created and shared so a cold redeploy works even if the
+# network was last created under a different project name.
+networks:
+  default:
+    name: matchmaking-v2_default
+    external: true
+
+# Project-scoped volume — the live `matchmaking-v2_matchmaking_pgdata` (47.7M PG
+# cluster) is reused as-is. No rename, no migration, no data risk.
+volumes:
+  matchmaking_pgdata: