…ech#21498)

## Background

erigontech#21483 added `fail-fast: ${{ github.event_name == 'merge_group' }}` to
`test-hive-eest.yml` only, with the explicit note that other
matrix-bearing reusable workflows could get the same treatment "if
another workflow becomes the bottleneck." It has — and there is also a
second problem erigontech#21483 didn't address: **GitHub does not auto-remove the
failed PR from the merge queue**.

CI Gate run
[26573584442](https://github.com/erigontech/erigon/actions/runs/26573584442)
for PR erigontech#21374 demonstrated both gaps:

- `hive-eest / rlp, serial` failed at 14:29:49 from a transient Docker
Hub blip (`alpine:latest` manifest HEAD returned `unknown:` while
building `hive/hiveproxy`).
- hive-eest's `fail-fast` cancelled siblings in **1 second**; `hive /
test-hive` (still on `fail-fast: false`) kept dispatching matrix legs —
`engine, api, serial` and `engine, cancun, parallel` started at 14:36:01
/ 14:36:17 (~7 min *after* `gh run cancel`) and ran to `success`.
ci-gate couldn't reach a terminal state until those finished at
14:43:54, delaying eviction by **~14 minutes**.
- Even once ci-gate reported `conclusion: failure` at 14:44:05, GitHub
did **not** remove PR erigontech#21374 from the queue: the entry stayed at
position 2 with state `UNMERGEABLE`. The queue only advanced because PR
erigontech#21483 was manually `jump`ed over it.

## Changes

### 1. Roll out merge_group fail-fast to the remaining matrix workflows

Same gating as erigontech#21483 (`${{ github.event_name == 'merge_group' }}`),
applied to:

- `test-hive.yml`
- `test-all-erigon.yml`
- `test-all-erigon-race.yml`
- `test-eest-spec.yml`
- `test-bench.yml`
- `test-kurtosis-assertoor.yml`

Behaviour matches erigontech#21483: in `merge_group`, first failed shard cancels
its siblings at the GitHub API layer (no waiting for runner drain); in
`pull_request` / `schedule` / `workflow_dispatch`, all shards continue
so authors keep the full per-shard breakdown.

### 2. Auto-dequeue UNMERGEABLE PRs whose required check failed

New step at the end of `ci-gate.yml`'s ci-gate job:

```yaml
- name: Dequeue failed merge-queue PR
  if: failure() && github.event_name == 'merge_group'
  ...
```

The step:

1. **Inspects `needs.*.result` and skips when all are `cancelled` with
no `failure`.** That pattern is a queue reshuffle (a PR ahead of us
merged, our merge-group SHA is stale), where GitHub re-creates a new
merge_group event for us; dequeuing here would be wrong. Confirmed by
run
[26573568764](https://github.com/erigontech/erigon/actions/runs/26573568764),
where ci-gate's job conclusion was `failure` (needs cancelled → `Check
all required jobs` exits 1) but the *run* was cancelled by GitHub during
a reshuffle.
2. Parses the PR number from `gh-readonly-queue/<base>/pr-<N>-<sha>`
(handles multi-segment bases like `release/3.4`).
3. Resolves the PR number to a GraphQL node ID and calls the
`dequeuePullRequest` mutation. Soft-fails on errors (warning, not
non-zero exit) so a dequeue glitch never masks ci-gate's own failure
signal.

Permissions bumped from `pull-requests: read` to `pull-requests: write`
for the mutation.

## Why both in one PR

Both target the same incident class (broken PR sits at the head of the
queue blocking everything else). The fail-fast change shrinks
time-to-fail for ci-gate from ~14 min to seconds; the dequeue actually
evicts the failed PR. Either alone is a partial fix — having both means
a broken PR's run goes red fast *and* the queue advances without anyone
needing to manually jump over it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: info@weblogix.biz <admin@10gbps.weblogix.it>

…igontech#21504)

## Why

Both merge-queue failures of erigontech#21374 were transient CI infrastructure
blips on network-dependent steps that had **no retry** — not problems
with the PR's code:

- **Docker Hub registry error** building hive's `hiveproxy` image: `Head
https://registry-1.docker.io/v2/library/alpine/manifests/latest:
unknown:` → `Tests: , Failed:` (zero tests ran).
- **github.com 403** during the in-builder erigon clone (`fatal: unable
to access 'https://github.com/erigontech/erigon/': 403`). That specific
path is already largely addressed by erigontech#21447 (build erigon locally
instead of cloning inside hive's builder), but the Docker Hub base-image
pulls remain in both `docker build` and `./hive`.

The merge-queue contract (per `CI-GUIDELINES.md`) is "a failure means
the code is wrong — zero false positives." These infra blips are exactly
the false positives that contract forbids, and they re-queue whole
batches.

## What

Add a small retry to the network-dependent steps in both `test-hive.yml`
and `test-hive-eest.yml`:

- **Build steps** (`docker build` of the local erigon image, `go get`,
`go build`): wrapped in a `retry()` helper — 3 attempts, linear backoff.
- **`./hive` run**: retried **only when too few tests were parsed**
(`tests < 4`) — the signature of a setup/image-build failure. A
completed run (`tests >= 4`) is judged on its first result and never
retried.

## Why this is safe for the merge queue

- A **genuine test failure is never retried** — only the *fast*
infra-setup failure path is, so the retry cannot mask a real regression.
- Because retries only trigger on the fast-fail (image build dying in
seconds), added latency is seconds + backoff, not multiplied test
runtime.
- This is step-level resilience, not reliance on merge-queue re-runs
(which `CI-GUIDELINES.md` explicitly discourages as a flake mask).

## Testing

- Verified the retry logic locally under `bash -e -o pipefail` (the
shell GitHub uses for `run:` steps): infra-fail-then-recover → passes
after retry; genuine failure → not retried, fails immediately;
persistent infra failure → retries to max then fails.
- `actionlint` clean — no new shellcheck findings (and removes one
pre-existing SC2181).
- `make lint` → 0 issues.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>