Bake the uv and Bazel caches into the sandbox image instead of Docker volumes

On #315 jbcoe asked, after #330 baked the googletest checkout into the sandbox image:

> Should we do the same for UV and bazel cache? We can then dispense with Docker volumes altogether.

Today the sandbox mounts two named volumes (`scripts/agentic-sandbox.py`, `CACHE_VOLUMES`): `cc-protocol-uv-cache` at `~/.cache/uv` (#301) and `cc-protocol-bazel-repository-cache` at `~/.cache/bazel-repo`, fed from the image's `~/.bazelrc` (#304). Both exist so a warm sandbox builds without the network.

Baking them in would mean running `uv sync` and `bazel fetch //...` in the sandbox stage of `docker/Dockerfile`, with the same `~/.cache/uv` and `~/.cache/bazel-repo` paths, so the image already holds every wheel and every external repository the build needs. The Bazel fetch must go through the repository cache and not rely on the output base, which is keyed by the workspace path. What that changes:

- No volumes at all: `--cache-volumes`/`--no-cache-volumes`, `UV_LINK_MODE=copy` and the pre-created mount points go away, and there is no shared writable state, which is what made #315 hard.
- The image is the cache. A `uv.lock` or `MODULE.bazel` change needs `--rebuild-docker`, the same rule #330 set for the googletest tag; until then the sandbox falls back to the network for the missing artefacts, exactly as it does now on a cold volume.
- Image size grows by the wheel set and the Bazel external repositories (everything `MODULE.bazel` pulls in). Worth measuring before deciding.
- `docker run --network none` on the built image then proves the offline claim end to end, which is the check #325 asks CI to make.

Things to decide: whether the Bazel fetch belongs in the image or should stay a volume because external repositories change more often than `uv.lock`; and whether the devcontainer stage should share any of this or keep its local caches as it does today.