fix(stack): preload runtime images via k3s crictl

[bussyjd]

Summary

Fixes the noisy k3d image import failure seen during dev obol stack up for public multi-arch runtime images such as OpenClaw and Hermes.

Instead of host docker pull + k3d image import, upstream runtime preloads now run inside the k3d server node with crictl pull, with a k3s crictl pull fallback. Locally built Obol dev images still use the existing cached k3d image import path.

Root Cause

k3d image import saves/imports the public multi-arch OCI index. On Docker Desktop/containerd-store setups, the saved tar can reference sibling platform manifests that are not present in the local content store. The node-side import then logs errors like content digest sha256:... not found; in the observed case, the missing digest was the linux/amd64 child manifest while the host was using linux/arm64 content.

Changes

• Preload devPreloadImages() through docker exec k3d-<cluster>-server-0 crictl pull <ref>.
• Fallback to docker exec ... k3s crictl pull <ref> when standalone crictl is unavailable or fails.
• Keep cached k3d image import for locally built images only.
• Update the Hermes preload comment to describe the new CRI path.
• Add tests covering the new runtime preload path and fallback.
• Update stale stack test expectations for the existing "No chat-capable model detected" warning string so the package gate passes.

Validation

• go test ./internal/stack -count=1
• Reproduced that the current stack is healthy after the original warning: all pods Running.
• Built and deployed the frontend marketplace tip with just dev-frontend using OBOL_DEVELOPMENT=true; rollout is live on localhost:54103/obol-stack-front-end:dev@sha256:8b3f232e9ea19461cab9a4e5da2ef2c2a6fc2ffaf609c1003ef247b5672075f5.