Fix healthcheck + verify commands; reframe deploy runbook for a capable agent

Real bug: the container healthcheck (and the docs' verify step) hit
/api/capabilities, which returns 403 unauthenticated; curl --fail treats
403 as an error, so a healthy container would report "unhealthy" and the
verify step would look like a failure. Healthcheck now hits /accounts/login/
(200, no auth). Verify commands now print the status code and note not to
use curl -f on the 403.

Also reframed cloud_agent_deploy.md's intro for an Opus-class deploy agent:
it's a guide + Daybook-specific gotchas, not a rigid script — points at the
authoritative sources (repo incl. the git-SSH :2222 note, deploy/ files,
requirements.txt deps auto-installed, entrypoint runs migrate+collectstatic,
docs/deployment.md) and trusts the agent's judgment. Dropped the now-
redundant Source Of Truth section.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/docker-compose.yml

@@ -22,7 +22,11 @@ services:
     volumes:
       - ${DAYBOOK_HOST_DATA_DIR:-./data}:/data
     healthcheck:
-      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8000/api/capabilities"]
+      # Hit the login page, not /api/capabilities: capabilities returns 403
+      # when unauthenticated, and `curl --fail` treats 403 as an error, which
+      # would mark a perfectly healthy container unhealthy. The login page
+      # serves 200 without auth and still proves Django is up and responding.
+      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8000/accounts/login/"]
       interval: 30s
       timeout: 5s
       retries: 5