docs(445): note the ci-image-pin length guard in the rebase-trap warning

Second pin-recovery cycle on this branch — main moved twice during review and each
rebase rewrites the sha of the commit that touched docker/ci. Records that #598 now
length-checks the pin at exactly 7 chars, which turns a locally-computed 8-char
`git rev-parse --short` into a loud gate failure instead of a confusing
manifest-unknown at image-pull time. That guard came from #594, filed by this
session after hitting exactly that ambiguity.

This commit also IS the recovery: it touches docker/ci, so ci-image.yml tags it and
the pin can be re-pointed in the follow-up commit.

Refs #445 #594

docker/ci/Dockerfile

@@ -19,8 +19,11 @@
 #
 # ⚠️ If a branch carrying a change to THIS file gets rebased, `ci-image-pin` goes red: the pin must
 # equal the short sha of the commit that touched docker/ci, and a rebase rewrites it. Re-dispatching
-# ci-image.yml does not help — it tags the branch HEAD, not this commit. Recovery and the reason to
-# land toolchain changes on their own first: docs/ci-cd.md -> "CI toolchain image".
+# ci-image.yml does not help — it tags the branch HEAD, not this commit. It cost ersatztv#445 two
+# recovery cycles because main moved twice mid-review. The pin is also length-checked (exactly 7
+# chars, ersatztv#594) so a locally-computed 8-char `--short` now fails loudly at the gate instead of
+# at image-pull time. Recovery, and the reason to land a toolchain change on its OWN branch BEFORE
+# the work that consumes it: docs/ci-cd.md -> "CI toolchain image".
 
 # Keep the ffmpeg tag on the FROM below equal to the one docker/Dockerfile pins, so CI's ffmpeg
 # stays prod-identical. Renovate manages both pins (dockerfile manager); mirror any bump here.