Deploy: drop cpus: limits and stop assuming docker compose exists

Two NAS realities, both hit on a real Synology box.

- "NanoCPUs" error part-way through the project build: `cpus:` maps to the
  NanoCPUs field, which DSM's Docker daemon rejects. Removed from all three
  services (and from .env.prod.example). mem_limit uses the much older Memory
  field and works, so memory caps remain the throttle. Noted in the header
  next to the other DSM constraints.
- `docker compose build` on DSM: "'compose' is not a docker command". DSM and
  QTS ship the standalone `docker-compose` binary with no plugin subcommand,
  so every one of the script's 21 compose invocations was wrong for the target
  platform. The script now detects which is present, and only passes `--wait`
  when it finds v2 — on v1 it falls back to the health_gate it already had,
  which is also now run after `up` on both paths.

That the build reached container creation before failing says their compose
parses the rest of the file (anchors, profiles, service_completed_successfully,
top-level name), so this was a daemon-level rejection, not a schema one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw

docker/.env.prod.example

@@ -91,6 +91,8 @@ STREAM_PARSE_MB=8
 PER_HOST_CONN_CAP=10
 HOT_BUDGET_PER_WORKER=50
 
+# Container caps. Memory only: CPU limits (`cpus:`) are deliberately absent
+# because Synology's Docker daemon rejects them (NanoCPUs).
 # Container caps. Total without Meilisearch: ~2.2 GB of *limits*; real steady
 # usage for one or two mail accounts is around 700 MB-1 GB.
 PG_MEM_LIMIT=768m
@@ -102,10 +104,8 @@ PG_EFFECTIVE_CACHE_SIZE=768MB
 REDIS_MEM_LIMIT=160m
 REDIS_MAXMEMORY=96mb
 API_MEM_LIMIT=512m
-API_CPUS=1.0
 WORKER_SYNC_MEM_LIMIT=512m
 WORKER_JOBS_MEM_LIMIT=640m
-WORKER_CPUS=1.5
 WEB_MEM_LIMIT=96m
 BACKUP_MEM_LIMIT=256m
 MEILI_MEM_LIMIT=1g