CI: firmware-build has no retry when the ESP-IDF image pull fails

[PurpleSentinel]

Objective

firmware-build failed on #153 in 6 seconds, before compiling anything:

docker: Error response from daemon: Head
"https://registry-1.docker.io/v2/espressif/idf/manifests/v6.0.2":
received unexpected HTTP status: 500 Internal Server Error

A re-run of the identical commit passed in 6m4s. Registry-side transient, nothing to do with
the change under test.

Why #147 did not cover this

#147 added per-attempt timeouts and retries to the apt step in simulator-checks, because
that failure was a hang. This one is the opposite shape: the pull fails fast and
correctly, so the timeout-minutes added there is exactly the wrong tool. What it needs is
the retry half, which firmware-build never got — the step is a bare docker run that pulls
espressif/idf:v6.0.2 implicitly.

Both are the same underlying exposure: every CI job depends on a third-party network fetch,
and a bad minute at Docker Hub or the Ubuntu archive fails a pull request that has nothing
wrong with it. Each one has to be pushed through by hand.

Scope

• Retry the image pull, with backoff, so a transient registry error costs seconds rather
  than a red check and a manual re-run
• Pull explicitly before running, so a registry failure is distinguishable in the log from
  a genuine build failure. Both currently surface as "firmware-build failed"
• Consider pinning by digest rather than tag, which makes the pull cacheable and the
  toolchain reproducible in a way v6.0.2 alone does not guarantee

Frequency so far

Three CI failures in recent pull requests have been infrastructure rather than code: apt
hanging twice (#147) and this. Worth fixing properly rather than re-running each time.