Image builds keep compiled crates between builds (#438)

The ipx Dockerfile built its dependencies in a layer of stub crates,
which any change to Cargo.toml or Cargo.lock invalidated: all of them
compiled again in release, 405 crates, 170 s at the builder's cap. The
directory's had no such layer and compiled everything every time. Both
now build with cargo's registry and target/ as BuildKit cache mounts.
Measured on Tower: a Cargo.toml change rebuilds three crates in 52 s
instead of 405 in 170 s. The peak is about the same, since the ipx
crate itself is most of it; what goes is the minutes at the cap.

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

CLAUDE.md

@@ -114,7 +114,9 @@ split lands means the frontend and directory too. Run `pull` before `up`, becaus
 not Docker Hub, which rate-limits this host with `429 Too Many Requests`. The capped builder
 cannot see images the Docker daemon has stored, so pulling and tagging them locally does nothing
 for it. If `buildkitd.toml` changes, remove the builder (`docker buildx rm ipx-capped`) so the
-next build makes it again with the new config.
+next build makes it again with the new config. The builder also keeps the compiled crates
+between builds (cache mounts, #438), so a `Cargo.lock` change compiles only what changed; removing
+it throws them away, and the next build of each image compiles all of them again.
 
 The containers have no Docker healthcheck (#218): Docker runs one with `exec`, which on Tower
 fails whenever root is logged out, because elogind removes `/run/user/0`, where containerd puts