Fix backup step to follow the configurable data path (F1)

A follow-up review of the previous fix caught that M1's DAYBOOK_HOST_DATA_DIR
override wasn't carried through to the backup step or checklist - both still
hardcoded deploy/data. Exactly when the override matters (a host with a
separate/larger volume), the backup would silently tar the wrong directory
while the checklist still read as complete.

Backup and checklist now derive the path from deploy/.env instead of
restating it. Also documents in docker-compose.yml why the .env
interpolation only resolves correctly when invoked as
`docker compose -f deploy/docker-compose.yml`, per a non-blocking note from
the same review.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

deploy/cloud_agent_deploy.md

@@ -211,8 +211,9 @@ docker compose -f deploy/docker-compose.yml up -d --build
 to roll back, then report the failure (build log / migration error / failed
 health check) back to the operator rather than retrying blindly.
 
-`deploy/.env` and `deploy/data/` are untracked, so `git pull` never touches
+`deploy/.env` and the data directory (wherever `DAYBOOK_HOST_DATA_DIR` points,
-them — no need to back them up before a routine redeploy.
+or `deploy/data` by default) are untracked, so `git pull` never touches them —
+no need to back them up before a routine redeploy.
 
 ## 8. Hardening For Internet-Facing Deployments
 
@@ -261,8 +262,15 @@ daybook.example.com {
 
 ## 9. Backup
 
+If you set `DAYBOOK_HOST_DATA_DIR` in step 5, the real data lives there, not
+at `deploy/data` — back up whichever path is actually configured, read
+straight from `deploy/.env` rather than assumed, so this keeps working
+whether or not that override is set:
+
 ```bash
-tar -czf /tmp/daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data
+cd /opt/daybook
+DATA_DIR="$(grep -oP '(?<=^DAYBOOK_HOST_DATA_DIR=).*' deploy/.env || echo deploy/data)"
+tar -czf "/tmp/daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz" -C "$(dirname "$DATA_DIR")" "$(basename "$DATA_DIR")"
 ```
 
 Copy the resulting archive off the VM (to object storage, the operator's
@@ -281,7 +289,8 @@ Before reporting the deployment complete, confirm all of these:
 - [ ] At least one superuser exists with a working personal API token.
 - [ ] A smoke-test artifact posts and renders successfully.
 - [ ] If internet-facing: TLS is in front of the app, not raw HTTP on `8000`.
-- [ ] A backup of `deploy/data/` has been taken and copied off the VM.
+- [ ] A backup of the data directory (`deploy/data`, or `DAYBOOK_HOST_DATA_DIR`
+      if you set it) has been taken and copied off the VM.
 - [ ] If the target host has its own service-inventory, monitoring, or
       changelog conventions for new services, they've been followed — ask
       the operator if unsure what those are.

deploy/docker-compose.yml

@@ -1,3 +1,11 @@
+# ${VAR} substitution below (DAYBOOK_BIND_ADDR, DAYBOOK_HOST_DATA_DIR) reads
+# from deploy/.env because Compose resolves .env relative to *this file's*
+# directory, not the caller's cwd. That relies on being invoked as
+# `docker compose -f deploy/docker-compose.yml` from the repo root, per
+# deploy/cloud_agent_deploy.md and docs/deployment.md. If that invocation
+# pattern ever changes, re-verify these still resolve — a silent fallback to
+# the defaults (0.0.0.0 bind, ./data) would be a security regression, not
+# just a broken build.
 services:
   daybook:
     build: