…lures (erigontech#21693)

## Problem

The `build-erigon-image` job in the kurtosis workflows
(`test-kurtosis-assertoor.yml`, `test-kurtosis-gloas.yml`)
intermittently fails on **transient infrastructure errors** unrelated to
the code — Docker Hub registry/auth blips and GitHub Actions
cache-backend hiccups. `docker/build-push-action` has no retry input, so
any such blip fails the whole job (and, in the merge queue, the run).

## Evidence (last ~30 days)

Scanning every failed `build-erigon-image` job across Cache Warming + CI
Gate runs, **4 of 15** failures were transient infra (the other 10 were
real compile breaks clustered on feature branches, plus one GitHub-CDN
action-download blip):

| Date | Branch | Signature |
|------|--------|-----------|
| 06-08 | main | Docker Hub `auth.docker.io/token` → `504 Gateway
Timeout` |
| 06-02 | main | `registry-1.docker.io … context deadline exceeded` |
| 06-02 | glamsterdam-devnet-4 | `registry-1.docker.io … request
canceled` (timeout) |
| 05-28 | main | GHA cache blob write 5xx
(`…blob.core.windows.net/actions-cache…`) |

That's ~3–4/month (≈ once a week), and a floor — flakes that someone
re-ran to green don't show as failed runs.

## Change

Retry the `docker/build-push-action` step once: the first attempt gets
an `id` + `continue-on-error: true`, and a second step re-runs the
identical build only `if: steps.build_erigon_image.outcome ==
'failure'`. The BuildKit layer cache (and the in-job builder) make the
retry cheap — it reuses the slow Go compile and only re-attempts
whatever flaked (pull / auth / cache export). Applied to both kurtosis
workflows.

## Why this approach

- `docker/build-push-action@v6` has no `retry` input (verified against
its `action.yml`), so retry must be external.
- Keeping the action — vs. converting to a raw `docker buildx build`
bash loop — preserves the auto-wired GHA cache runtime token and avoids
adding a third-party action (`crazy-max/ghaction-github-runtime`).
- Retrying the whole step covers cache-export failures too, not just
registry pulls.

## Tradeoff

A retry can't distinguish a transient flake from a real compile error,
so genuine build breaks now take 2 attempts before failing (~2× feedback
time on a broken build). The retry step has no `continue-on-error`, so
real breaks still go red — they are not masked.

## Validation

- `actionlint` clean for both files (the two `SC2086` infos it prints
are pre-existing, in untouched `run:` blocks).
- Behaviour: attempt 1 succeeds → retry skipped; attempt 1 fails +
attempt 2 succeeds → job green, image present for the downstream
artifact/test steps; both fail → job red.

## Precedent

Same pattern as erigontech#21604 (retry SonarCloud scan), erigontech#21602 (retry kurtosis
engine bootstrap), and erigontech#21504 (retry hive image-build/registry
failures).

…orkflow (erigontech#21703)

## Problem

`test-kurtosis-gloas.yml` restores the `docker-cl-*` third-party image
cache but nothing ever warms it on the default branch:

- It triggers on `pull_request` + `workflow_dispatch` only — no `push` /
`merge_group` / `schedule`.
- Its cache `save` is gated `github.event_name != 'pull_request'` (since
erigontech#21602), and its only non-PR trigger is manual `workflow_dispatch`.

So the cache is never systematically populated on the default branch,
and gloas PR runs cold-pull all 7 third-party images from Docker Hub on
~every run — exposed to the same Docker Hub flakes as the assertoor
workflow, protected only by the 3-attempt retry.

This is a **different cache key** from the assertoor warmer (erigontech#21695) —
gloas's key omits `TEKU` — so that warmer doesn't cover it. And unlike
assertoor, gloas does **not** run in `merge_group`, so a flake here
fails a PR check rather than bouncing the merge queue — lower blast
radius, same root gap.

## Fix

Mirror erigontech#21695 for gloas:

- Make `test-kurtosis-gloas.yml` callable (`workflow_call`) with a new
**`cl-images-only`** input that runs *only* a new
`warm-third-party-images` job; the `gloas_test` matrix is gated off
under it.
- The warm job uses **`actions/cache/restore@v5` (`lookup-only`)** + an
explicit **`actions/cache/save@v5`** on miss — a ~10 s no-op when the
cache already exists, pull + save only on a genuine miss.
- New **`cache-warming-kurtosis-gloas-images.yml`** drives it on `push`
to `main`/`release/**` filtered on `paths: [test-kurtosis-gloas.yml]`
(re-warm on version bumps) + a daily `schedule` (repopulate after LRU
eviction at the 500 GB cache ceiling) + `workflow_dispatch`.

Net effect: gloas PR runs restore the cache from the default branch
instead of pulling from Docker Hub.

## Notes

- Follow-up to erigontech#21695 (assertoor CL cache); same pattern, gloas's own
key/image set (no teku).
- The pinned image versions are duplicated across
`test-kurtosis-assertoor.yml` and `test-kurtosis-gloas.yml` (and now
their two warmers). Unifying them into a single source so one warmer
covers both is a sensible future cleanup — called out, not done here.

## Validation

- `actionlint` clean on both workflows (the one `SC2086` info is
pre-existing, in an untouched `run:` block).
- Gating: with `cl-images-only`, only `warm-third-party-images` runs; on
`pull_request` / `workflow_dispatch` (no input), `gloas_test` runs as
before. The PR-merge touches `test-kurtosis-gloas.yml`, so the `paths`
trigger warms the cache on merge — no cold-start gap.

Co-authored-by: lystopad <oleksandr.lystopad@erigon.tech>