EXPERIMENT ONLY: measure Zephyr CI container pull time on a hosted runner

[dhalbert]

Claude wrote this, for @dhalbert. Not for merging.

Measures what a container-based zephyr-cp job would pay on a hosted runner, to compare with today's ~3 minute setup step (west update 68 s, pip 44 s, SDK cache restore 18 s, apt ~30 s):

• pull-times: pulls ghcr.io/zephyrproject-rtos/ci-base, ci and ci-repo-cache at the tag our Zephyr revision's own CI uses, and prints the times and image sizes.
• inside-repo-cache-container: runs inside ci-repo-cache. Its "Initialize containers" step is the pull-and-start cost a real container job pays before its first step; the job then times west init and west update against the image's repo cache.

The workflow only triggers on changes to itself, and it is added to IGNORE_BOARD in ci_set_matrix.py so this PR builds no boards.

[dhalbert]

Claude wrote this:

Results from run 35415684574, on a fresh ubuntu-24.04 runner.

Image (ghcr.io/zephyrproject-rtos)	Size on disk	Pull
ci-base:v0.29.2 (SDK and tools, no modules)	8.6 GB	119 s
ci:v0.29.2	22.5 GB	150 s more, sharing layers with ci-base
ci-repo-cache:v0.29.2.20260422 (adds an 8.5 GB west repo cache)	31 GB	137 s more; as a container: job, 359-424 s in "Initialize containers" before the first step

Inside the repo-cache container, west update --path-cache /repo-cache/zephyrproject still took 67 s, the same as cloning the 37 modules from GitHub, because the working trees still have to be materialized.

Today's zephyr-cp setup step is about 176 s (west update 68 s, pip 44 s, SDK cache restore 18 s, apt ~30 s). The cheapest container costs 119 s before the first step and still needs the module fetch and the pip install, so it is no faster, and the image that holds the modules is two to four times slower. Containers would only pay on self-hosted runners with a warm image store.

Same conclusion as #10885, which also covers the mount-shadowing problem with submodule and west directories and the image maintenance cost. Closing; not for merging.