ci: warm test-bench cache on push to main (#19968)

## Problem

`test-bench` only triggered on `pull_request`, so there was never a
base-branch cache on `main`. GitHub's cache isolation allows workflow
runs to fall back to the base branch — but not to other PRs or branches.
Without a `main` cache:

- Every new PR's first push starts completely cold (full module download
+ recompile)
- Merge-queue runs (`merge_group`) also start cold — they can read from
`main` but not from other PRs
- Caches saved during merge-group runs are stored under the temporary
`gh-readonly-queue/...` branch and become inaccessible once the merge
group completes; they never contribute to `main`

## Fix

Add `push` triggers for `main` and `release/**`. After each merge, a
cache-warming run compiles all test binaries and saves them under the
`main` branch scope. Future PR first-pushes and merge-queue runs restore
from that warm cache.

On non-`pull_request` events, the benchmark execution step is replaced
with `go test -run=^$ ./...` — this compiles every test binary
(producing identical GOCACHE entries) but runs nothing. The job always
succeeds on `main` because correctness is already guaranteed by the
merge queue before the commit lands.

Also adds `workflow_dispatch` (required by project guidelines) and
documents the cache isolation model and compile-only warming pattern in
`.github/README.md`.

Author: anacrolix

.github/README.md

@@ -94,6 +94,58 @@ unnecessary re-runs.
 This is also why the `execution/tests/` package is broken into focused sub-packages
 rather than one monolithic package.
 
+### Cache warming and GitHub's cache isolation rules
+
+GitHub Actions caches are scoped by branch. A workflow run can restore caches from:
+
+1. **Its own branch** — caches saved by earlier runs on the same branch.
+2. **The base branch** (`main`) — caches saved by any workflow run on `main`.
+
+It cannot access caches from other PRs or other branches.
+
+**The cold-start problem** — If a workflow only triggers on `pull_request`, it never
+runs on `main` and therefore never populates the base-branch cache. Every new PR
+opens to a cold cache, even if the codebase hasn't changed at all. Subsequent pushes
+to the *same* PR do find each other's caches, but only until the GitHub-hosted cache
+is evicted (repos share a 10 GB limit; busy repos evict older entries within hours).
+
+**The fix** — add `push: {branches: [main, release/**]}` as a trigger. After each
+merge, a run warms the build and module caches on `main`. All future PR first-pushes
+restore from that warm base-branch cache instead of starting cold.
+
+**Cache warming without test validation** — For workflows where correctness is already
+enforced by the merge queue, the push-to-main run exists purely for cache warming. To
+prevent benchmark or test flakiness from showing as failures on main commits, use
+compile-only steps on non-PR events:
+
+```yaml
+- name: Run benchmarks
+  if: github.event_name == 'pull_request'
+  run: make test-bench
+
+- name: Build test binaries (cache warming)
+  if: github.event_name != 'pull_request'
+  run: go test -run=^$ ./...
+```
+
+`go test -run=^$` compiles every test binary (identical GOCACHE entries to a full
+run) but executes nothing. The job always succeeds, and the commit on `main` shows
+green. If a benchmark were broken post-merge it would have been caught by the PR or
+merge queue run before landing.
+
+**Merge queues** — `merge_group` runs use a temporary synthetic branch
+(`refs/heads/gh-readonly-queue/main/pr-N-SHA`). They can read from the base-branch
+(`main`) cache, so they benefit from the warm cache created by the `push` trigger.
+However, caches *saved* during a merge-group run are stored under that temporary
+branch and become inaccessible once the merge group completes — they do not
+contribute to the `main` cache. Only the `push`-triggered run after the merge creates
+a durable base-branch cache.
+
+**Implication for workflow design**: any workflow that should benefit from caching
+across PRs and merge queue runs needs a `push` trigger on `main` (or a nightly
+schedule on `main`). Without it, each PR and each merge-queue batch is always a cold
+start.
+
 ## Required checks
 
 Required checks exist to block *regressions*, not to enforce perfection.

.github/workflows/test-bench.yml

@@ -1,10 +1,9 @@
 name: Benchmarks
 
-# We only run benchmarks on pull requests to catch accidental breakage early.
-# We don't run on push to main/release because benchmarks aren't actively used
-# for anything right now — if they break post-merge it's not a release blocker.
-# If we ever care about benchmark results over time, that would be a separate
-# workflow on main that tracks performance trends, not this one.
+# Run benchmarks on pull requests to catch accidental breakage, and on push
+# to main/release to keep a warm build cache. Without a push trigger,
+# test-bench never runs on main and every new PR starts from a cold cache,
+# because GitHub's cache fallback chain only reaches the base branch.
 on:
   pull_request:
     branches:
@@ -14,6 +13,17 @@ on:
       - reopened
       - synchronize
       - ready_for_review
+  push:
+    # Cache warming only — benchmarks are not re-run on push to main/release.
+    # GitHub's cache isolation means PR and merge-queue runs can only fall back
+    # to the base-branch cache. Without this trigger, test-bench never runs on
+    # main so every new PR starts cold. The push run compiles test binaries
+    # (warming GOCACHE and GOMODCACHE) but does not execute them; correctness
+    # is already guaranteed by the merge queue before the commit lands here.
+    branches:
+      - main
+      - release/**
+  workflow_dispatch:
 
 defaults:
   run:
@@ -40,7 +50,12 @@ jobs:
         id: erigon
 
       - name: Run benchmarks
+        if: github.event_name == 'pull_request'
         run: make test-bench
 
+      - name: Build test binaries (cache warming)
+        if: github.event_name != 'pull_request'
+        run: go test -run=^$ ./...
+
       - uses: ./.github/actions/cleanup-erigon
         if: always()