…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).