docs(deploy): use the published :jazzy image, not a local build, in the k3d loop

Replaces the k3d loop's `podman build` step with `podman run --entrypoint
true ghcr.io/minipada/ros2_data_collection/dc-ros:jazzy` (and dc-uploader):
this repository already publishes these images on every push to jazzy, so
trying the loop doesn't require a full workspace build first. Also drops the
:dev tag and the docker.io/library/ retag it needed — ROS images are tagged
by distro codename, never :latest (ros:jazzy-ros-base, never ros:latest), and
this repo's own images follow the same convention (branch name, not
:latest), so the overlay now just repoints the base manifest's ghcr.io
:latest ref at :jazzy instead of introducing a separate local naming scheme.

Verified against the real published images (not stand-ins this time):
`podman run --entrypoint true` pulls and exits cleanly for both, and the
Kustomize overlay renders the correct ghcr.io/.../dc-ros:jazzy +
imagePullPolicy: Never. Confirmed cluster create is still ~15-20s. Couldn't
complete a live save+import+apply run with the real ~17 GB images in this
sandbox (a save needs that much disk again, on top of Podman's own copy, and
free disk here is under 4 GB) — that limit is sandbox-specific, not a defect
in the documented commands, but it's a real cost on any machine, so the docs
now call out the image size and what step it actually slows down (loading,
not the cluster or the manifest iteration after it).

Closes #451

Signed-off-by: David Bensoussan <d.bensoussan@proton.me>

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011mBacgaX1VbBvWUfK3RQKU
Signed-off-by: David Bensoussan <d.bensoussan@proton.me>

Author: Minipada

deploy/robot/README.md

@@ -78,14 +78,16 @@ normally costs. There is no wrapper script — every step below is a plain `podm
 `kubectl` command, so what the loop actually does is never hidden behind a script:
 
 ```sh
-# 1. Build the two images this repository ships, tagged for local use. The
-#    docker.io/library/ prefix matters: it's what a bare `image: name:tag` in the
-#    manifest resolves to once it reaches the cluster's containerd, and Podman would
-#    otherwise namespace a locally-built image as localhost/name:tag instead — a
-#    mismatch that surfaces as ErrImageNeverPull despite the image having imported
-#    "successfully".
-podman build -t docker.io/library/dc-ros:dev -f containers/dc-ros/Containerfile containers/dc-ros
-podman build -t docker.io/library/dc-uploader:dev -f containers/dc-uploader/Containerfile containers/dc-uploader
+# 1. Get the images into local Podman storage. This example uses the images this
+#    branch already publishes, tagged :jazzy — ghcr.io tags follow the branch name
+#    here, never :latest, the same way ROS's own images are tagged by distro codename
+#    (ros:jazzy-ros-base), never ros:latest. --entrypoint true skips actually launching
+#    DC; this step exists only to fetch the image. To test your own local changes
+#    instead, build containers/dc-ros/Containerfile the same way CI does (BASE_IMAGE
+#    from tools/e2e/scripts/build.sh) and tag the result identically — nothing below
+#    changes.
+podman run --rm --entrypoint true ghcr.io/minipada/ros2_data_collection/dc-ros:jazzy
+podman run --rm --entrypoint true ghcr.io/minipada/ros2_data_collection/dc-uploader:jazzy
 
 # 2. Create the cluster. --volume stages params/robot_params.yaml where
 #    kubernetes/robot-pod.yaml's hostPath volume expects it, on the node itself
@@ -98,36 +100,41 @@ k3d cluster create dc-robot-dev \
   --volume "$(pwd)/deploy/robot/params:/etc/dc/robot@server:0" \
   --k3s-arg '--kubelet-arg=feature-gates=KubeletInUserNamespace=true@server:*'
 
-# 3. Load the images straight into the cluster's containerd — no push, no pull, no
-#    registry. `podman save` refuses to overwrite a tar it already wrote, hence `rm -f`
-#    on each iteration.
-rm -f /tmp/dc-ros.tar && podman save docker.io/library/dc-ros:dev -o /tmp/dc-ros.tar && k3d image import /tmp/dc-ros.tar -c dc-robot-dev
-rm -f /tmp/dc-uploader.tar && podman save docker.io/library/dc-uploader:dev -o /tmp/dc-uploader.tar && k3d image import /tmp/dc-uploader.tar -c dc-robot-dev
-
-# 4. Run the Pod. `k3d/kustomization.yaml` overlays kubernetes/robot-pod.yaml: the two
-#    images above instead of ghcr.io, and imagePullPolicy: Never so kubelet uses what
-#    was just imported instead of trying (and failing — no registry exists for a local
-#    :dev tag) to pull it. `apply -k` itself refuses a base outside its own directory,
+# 3. Load the images straight into the cluster's containerd — no push, no further
+#    pull, no registry reachable from inside the cluster. `podman save` refuses to
+#    overwrite a tar it already wrote, hence `rm -f` on each iteration. These images
+#    are large (~17 GB as published today, since the runtime stage isn't stripped down
+#    from the build workspace) — this step needs that much free disk twice over
+#    (Podman's own storage, plus the tar) and is the slow part of the loop; everything
+#    after it is fast.
+rm -f /tmp/dc-ros.tar && podman save ghcr.io/minipada/ros2_data_collection/dc-ros:jazzy -o /tmp/dc-ros.tar && k3d image import /tmp/dc-ros.tar -c dc-robot-dev
+rm -f /tmp/dc-uploader.tar && podman save ghcr.io/minipada/ros2_data_collection/dc-uploader:jazzy -o /tmp/dc-uploader.tar && k3d image import /tmp/dc-uploader.tar -c dc-robot-dev
+
+# 4. Run the Pod. `k3d/kustomization.yaml` overlays kubernetes/robot-pod.yaml: pins
+#    both images to :jazzy instead of the base manifest's :latest, and sets
+#    imagePullPolicy: Never so kubelet uses what was just imported instead of reaching
+#    out to ghcr.io itself. `apply -k` itself refuses a base outside its own directory,
 #    which is why this pipes through `kustomize` (which accepts the override) instead.
 kubectl kustomize deploy/robot/k3d --load-restrictor LoadRestrictionsNone | kubectl --context k3d-dc-robot-dev apply -f -
 
 # 5. Watch it come up — same readiness signal verify_kube_play.sh checks.
 kubectl --context k3d-dc-robot-dev get pod dc-robot --watch
 kubectl --context k3d-dc-robot-dev logs dc-robot -c dc-ros --follow
 
-# 6. Iterate: rebuild an image, redo step 3, then recreate the Pod (Pod spec fields —
-#    including the image — are immutable in place, so this needs a delete first;
-#    cheap on a single-node cluster).
+# 6. Iterate: rebuild/re-pull an image, redo step 3, then recreate the Pod (Pod spec
+#    fields — including the image — are immutable in place, so this needs a delete
+#    first; cheap on a single-node cluster).
 kubectl --context k3d-dc-robot-dev delete pod dc-robot
 kubectl kustomize deploy/robot/k3d --load-restrictor LoadRestrictionsNone | kubectl --context k3d-dc-robot-dev apply -f -
 
 # 7. Tear down.
 k3d cluster delete dc-robot-dev
 ```
 
-Measured against this loop with placeholder images standing in for `dc-ros`/`dc-uploader`:
-cluster create ~15-20s, an image-reload-and-recreate iteration ~10s, teardown ~2s — fast
-enough to repeat many times in a session, which is the whole point.
+Measured against this loop: cluster create ~15-20s, an image-reload-and-recreate
+iteration ~10s excluding the save/import in step 3 (dominated by the image's own size,
+several minutes for a ~17 GB image), teardown ~2s. Once an image is loaded, iterating on
+the manifest itself (steps 4-6 without redoing step 3) is the genuinely fast part.
 
 This is **explicitly not** the production-parity check. k3d's default CNI (Flannel) does not
 enforce `NetworkPolicy`, so it cannot stand in for `verify_network_isolation.sh`'s isolation

deploy/robot/k3d/kustomization.yaml

@@ -1,25 +1,27 @@
 # SPDX-FileCopyrightText: 2022-2026 David Bensoussan
 # SPDX-License-Identifier: MPL-2.0
 
-# k3d dev-loop overlay (#451) over ../kubernetes/robot-pod.yaml (#450): points
-# dc-ros/dc-uploader at locally built images instead of ghcr.io, so a k3d cluster with
-# no registry configured can run the Pod — see ../README.md for the full command
-# sequence (`podman build`, `k3d image import`, `kubectl apply -k`). `vector` keeps
-# pulling the real upstream image unchanged; local-image substitution only applies to
-# what this repository actually builds.
+# k3d dev-loop overlay (#451) over ../kubernetes/robot-pod.yaml (#450): pins dc-ros/
+# dc-uploader to the :jazzy tag (this branch's own published tag — see ../README.md;
+# never :latest, the same way ROS's own images are tagged by distro codename, not
+# :latest) instead of the base manifest's :latest, and forces imagePullPolicy: Never
+# so the cluster runs entirely off whatever `k3d image import` already placed on the
+# node instead of reaching out to ghcr.io itself — see ../README.md for the full
+# command sequence (`podman run`, `k3d image import`, `kubectl apply -k`). `vector`
+# keeps pulling the real upstream image unchanged.
 #
-# `newTag: dev` is a convention, not a requirement — build with a different tag and
-# override `newTag` here, or pass `--set` at kustomize-build time.
+# Building your own image instead of using the published :jazzy tag (to test local
+# changes) needs no change here: tag your build identically
+# (ghcr.io/minipada/ros2_data_collection/dc-ros:jazzy) and it's what `podman save`
+# picks up in ../README.md's step 3.
 resources:
   - ../kubernetes/robot-pod.yaml
 
 images:
   - name: ghcr.io/minipada/ros2_data_collection/dc-ros
-    newName: docker.io/library/dc-ros
-    newTag: dev
+    newTag: jazzy
   - name: ghcr.io/minipada/ros2_data_collection/dc-uploader
-    newName: docker.io/library/dc-uploader
-    newTag: dev
+    newTag: jazzy
 
 patches:
   - path: pull-policy.yaml