docs(agents): how the containers and agents are actually set up

Written for the other machine, which asked. Everything in it was read off the
running host rather than remembered.

Also adds docker/ci/ -- the CI image recipe and a capped runner -- because the
image existed on exactly one host and its Dockerfile was in a scratch directory
under /tmp, which was swept. That is the same shape as every other thing this
consolidation has turned up: something correct that exists in one place.

  docker/ci/Dockerfile          rust 1.98.1 + the apt list copied from ci.yml
  docker/ci/Dockerfile.ffmpeg   + ffmpeg, which sylpheed-export shells out to
  docker/ci/run                 6 CPUs / 7 GB / NO SWAP, named cargo volumes

The rule the runner exists to enforce: every heavy command goes in the capped
container. CARGO_BUILD_JOBS caps codegen units, not rustc's threads, not the
linker, not the test harness -- a bare host build is unbounded and has frozen
this box repeatedly.

The document also records the two agent defects the other machine will meet:
a brief change does not reach a RESUMED session, and nothing brought an agent
back to its own red PR (fixed in #24, which is itself subject to the first).

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

docker/ci/Dockerfile.ffmpeg

@@ -0,0 +1,11 @@
+# `sylph-ci:ffmpeg` — the CI image plus ffmpeg, for `sylpheed-export`.
+#
+# The exporter shells out to `ffprobe`/`ffmpeg` to transcode the two movies, so
+# `cargo run -p sylpheed-export -- export` fails in the plain CI image with
+# "run ffprobe -- is it on PATH?". CI itself never runs the exporter, which is
+# why its own image does not carry this.
+#
+#   docker build -t sylph-ci:ffmpeg -f docker/ci/Dockerfile.ffmpeg docker/ci
+FROM sylph-ci:local
+RUN apt-get update && apt-get install -y --no-install-recommends ffmpeg \
+    && rm -rf /var/lib/apt/lists/*