…-queue runs (erigontech#21695)

## Problem

The kurtosis matrix's third-party images (lighthouse, teku, assertoor,
kurtosis engine/core/expander, vector, fluent-bit) are cached via
`actions/cache`, but that cache is **only ever written in PR scope,
never on the default branch** — so the merge queue gets no protection
from it.

Why: `cache-warming.yml` calls this workflow with `cache-warming-only:
true`, which skips the `assertoor_test` matrix job — the only job that
pulls + saves those images. So `docker-cl-*` is never saved to
`refs/heads/main`. (Every existing `docker-cl-*` cache entry is scoped
to `refs/pull/NNNNN/merge`.) Merge-queue runs execute on ephemeral
`gh-readonly-queue/main/*` branches and can only restore caches from the
default branch — so **every merge-queue run misses and pulls all 8
images from Docker Hub**, fully exposed to Docker Hub flakes on the path
that gates merges.

## Example failure


https://github.com/erigontech/erigon/actions/runs/27067265745/job/79891001617
— a merge-queue run for erigontech#21659. The
`assertoor_caplin-minimal_parallel_test` shard missed the cache, tried
to pull `sigp/lighthouse:v7.0.1`, hit `registry-1.docker.io … context
deadline exceeded` on all 3 retry attempts, and fast-cancelled the whole
merge-group run.

## Fix

Warm the `docker-cl-*` cache **on the default branch** via a dedicated
workflow (`warm-kurtosis-cl-images.yml`):

- **Triggers:** `push` to `main`/`release/**` filtered on `paths:
[test-kurtosis-assertoor.yml]` — the cache key is derived from the
pinned image versions, which live in that file, so it only needs
re-warming on a version bump — **plus a daily `schedule`** to repopulate
the cache if it's LRU-evicted between bumps (the repo sits at the 500 GB
cache ceiling, so eviction is active).
- It calls `test-kurtosis-assertoor.yml` with a new **`cl-images-only`**
input that runs *only* the warm job — `build-erigon-image` and the test
matrix are gated off, so the schedule/paths runs don't rebuild the image
or run tests.
- The warm job uses **`actions/cache/restore@v5` with `lookup-only:
true`** + an explicit `actions/cache/save@v5` on miss: when the cache
already exists it's a ~10 s no-op (no download), and it only pulls +
saves on a genuine miss.

Net effect: merge-queue and first-PR runs restore the CL cache from the
default branch instead of pulling from Docker Hub.

## Scope

- **`build-erigon-image` is intentionally left on its every-push
cadence.** Its BuildKit layer cache is source-dependent (the base + `go
mod download` layers track `Dockerfile`/`go.mod`/`go.sum`, the compile
layer changes every commit), a different concern from these static
version-pinned images. Optimizing *its* warming (paths on
`Dockerfile`/`go.mod`/`go.sum` + a deps-stage split so the warm skips
the compile) is a possible follow-up, not in this PR.
- Complementary to erigontech#21693 (retry on the erigon image build) — a
different Docker Hub touchpoint.

## Validation

- `actionlint` clean on both workflows (the one `SC2086` info is
pre-existing, in an untouched `run:` block).
- Gating verified: with `cl-images-only`, only `warm-third-party-images`
runs; `cache-warming.yml` (`cache-warming-only`) still warms
`build-erigon-image` every push; PR/merge_group still run the full
matrix and now restore the default-branch CL cache.