ci: layered Python base images for cross-matrix dedup

[richiejp]

Experiment to see if creating OS+vendor+language base images can massively reduce CI time and build time locally.

---

The 234-entry backend matrix runs the same apt-update + GPU SDK install +
Python toolchain bootstrap into N independent registry-cache tags. Factor
that shared work out into a tier-1+2 base image (lang × accel × ubuntu ×
cuda) built once per workflow run, then consumed by every backend that
matches its tuple via BASE_IMAGE_PREBUILT.

The matrix data moves to .github/backend-matrix.yaml so backend.yml can
switch to fromJSON without duplicating the matrix. scripts/changed-backends.js
reads the data file, derives the deduplicated bases-matrix, annotates each
Python entry with the right base-image-prebuilt ref, and runs a collision
check that fails loudly if a future matrix change makes two consumers want
incompatible bases under the same tag-stem.

PR builds tag with -pr so end-to-end validation lives within one PR;
master builds tag without the suffix. The base-images registry cache
parallels the existing per-matrix-entry caches.

Adding a new (accel, cuda) flavour is a backend-matrix.yaml edit; adding
a new language tier is a Dockerfile. recipe + a slim of the
consumer Dockerfile (script auto-detects via .docker/bases/).

10 distinct bases derive from the current 234 entries, replacing the
inline bootstrap that previously ran into ~10 separate cache tags.

Assisted-by: Claude:opus-4-7-1m [Claude Code]

[richiejp]

This doesn't solve the problem. Most of the time is spent doing backend specific stuff.

---

Per-run saving (steady state, after bases are cached):

• ~17 cpp consumers × 5-18m saved each ≈ 150-200 min of CPU time across the matrix
• golang/python/rust consumers: near-zero saving (their inlined apt+toolchain was small to begin with)

Cost we paid for it:

• 29 bases × ~36m mean = 1035 min CPU time, once, when bases change
• cpp-vulkan-2404 (5h17m) and cpp-cpu-2404 (4h33m) dominate — both because of QEMU multi-arch + GRPC compile

Wall-clock impact (what users see):

• The cpp matrix is gated on its base. The slowest cpp base (vulkan, 5h17m) becomes the new critical path for vulkan consumers when the base changes. Master parallelizes the GRPC
  build inside each consumer, so its critical path is just the slowest single consumer (~5h25m for vulkan-llama-cpp). Roughly a wash on cpp-vulkan; small win elsewhere.
• The 4 still-queued llama-cpp jobs are queued on bigger-runner — that's runner contention, nothing to do with this PR.

Bottom line: the saving is ~10-15% of cpp consumer time, paid for by a 17h one-time base build. It's a real but modest win, dominated by the GRPC step. The big ROI would come from
moving more work into bases (e.g. baking the protogen-go step or backend-specific deps that don't change often) — not from the layering itself.