Check the deployed revision, not just any 200, in the health poll

/api/health now reports REVISION alongside status, and the CI wait
step checks for this deploy's own short SHA specifically - a stray
old container that never got torn down (or a build that silently
kept serving stale code) would still 200 on a plain health check but
now won't match.

docs/deployment.adoc

@@ -246,8 +246,11 @@ a retagged image's old layers behind — turning every deploy into a
 full `apt-get`/`bundle install` from scratch (~3 minutes measured,
 vs. ~20s before). Fixed by adding `--build` to the unit instead (see
 above); don't reintroduce the `podman rmi` step.
-. Polls `http://localhost:4567/api/health` (up to 5 minutes, the job
-  fails if it never comes up) before calling the deploy done — the
-  restart above only confirms `podman compose up --build` was
-  launched (`Type=simple` has no readiness protocol), not that the
-  build actually succeeded and Puma is answering.
+. Polls `http://localhost:4567/api/health` for *this deploy's own*
+  revision (up to 5 minutes, the job fails if it never shows up)
+  before calling the deploy done — the restart above only confirms
+  `podman compose up --build` was launched (`Type=simple` has no
+  readiness protocol), not that the build actually succeeded and the
+  new code is what's answering; checking the revision specifically,
+  not just any 200, also catches a stuck old container that never got
+  torn down.