Fix health endpoint, align with the documented manual runbook

The health router is mounted at prefix="/api" in domaindingo's main.py, so
/health 404s. Checking it would have failed every deploy and rolled back a
perfectly good image.

Also adopts three conventions from the vault's DomainDingo Development note:
recreate a single named service (--no-deps --force-recreate), validate with
compose config --quiet before touching the running container, and write the
rollback record in the documented format and location.

docs/hints.md

@@ -37,3 +37,21 @@ Short notes on things that were not obvious. Prune stale ones.
 - **`docker compose down -v` destroys the data volumes** for these stacks. The
   retired paradicsomleves test script used it. `cd-deploy` only ever runs
   `up -d`.
+
+- **domaindingo's health endpoint is `/api/health`, not `/health`.** The route is
+  declared as `/health` in `src/domaindingo/api/status.py`, but `main.py` mounts
+  the router with `prefix="/api"`. Checking `/health` gets a 404, which reads as
+  a failed deploy and triggers a rollback. The vault's
+  "DomainDingo Development" note is the authority here.
+
+- **The manual runbook recreates one service, not the project.**
+  `docker compose up -d --pull always --no-deps --force-recreate <service>`.
+  `cd-deploy` matches it (minus `--pull always`, since it has already pulled a
+  pinned digest), so an automated deploy and a hand-run one converge on the same
+  state.
+
+- **Rollback records are a documented convention.**
+  `<service>-rollback-<UTC timestamp>.env` in `backup-test`/`backup-prod`,
+  holding `DD_ROLLBACK_IMAGE`, `DD_ROLLBACK_REVISION`, `DD_ROLLBACK_CAPTURED_AT`.
+  `cd-deploy` writes the same format in the same place, so an operator following
+  the manual note can recover from an automated deploy.