fix(bench-gpu): make the toolchain gate able to fail, and say why

[MauroToscano]

Review follow-ups for #939, targeted at that PR's branch so they land with it.

The headline one: the toolchain sanity gate could never fail. Under set -e, a non-final operand of an && list is exempt from errexit and the list's non-zero status does not re-trigger it, so a dead cc/rustc was swallowed and the remote exit status became that of the trailing rm -rf "$d". The step printed toolchain sane on a host whose compiler had just crashed, then the dual build died ~10 min later with exactly the internal-compiler-error backtrace the gate was added to prevent.

Measured against the gate body extracted verbatim from the workflow:

injected failure	before	after
cc exits 139 (ICE/SIGSEGV-like)	0	139
cc killed by real SIGSEGV	0	139
cc absent (127)	0	127
cc exits 1	0	1
rustc exits 139	0	139
rustc absent (127)	0	127
healthy box	0	0

Worth knowing what the gate did still catch before this change, since it was not fully inert: mktemp failure, a read-only fs, "compiler exits 0 but emits no/unrunnable binary", and ssh transport failure. What it was blind to was every compiler-side failure — the one class its own comment named.

Also in here

• ssh exit 255 is no longer read as a toolchain verdict. A network blip previously printed "this host's gcc/rustc is broken".
• The probe runs from the repo, so rustup resolves the pinned rust-toolchain.toml toolchain instead of the image's default.
• A failure in this step used to post an empty PR comment. The comment step tails $RUNNER_TEMP/abba_out.txt, which only the bench step writes, so a pre-bench failure rendered ❌ Run failed. Last log lines: above an empty fence — the actionable text never left the Actions log. Failures now record their reason and the compiler output there. (Pre-existing hole; ci(bench-gpu): stop building on half-provisioned or bad-RAM boxes #939 added two new paths into it.)
• The gate's error no longer asserts "bad RAM." It establishes "cc or rustc could not compile and run a trivial program"; bad RAM is offered as one cause alongside a partially provisioned image, which is the likelier one.
• The reroll advice now matches what the picker does. Both host-fault messages said "Re-run /bench-gpu to reroll the box", but selection is deterministic (sort_by(.dph_total) | reverse | .[0], no machine_id exclusion), so an immediate re-run can re-pick the same machine once it relists. They now say to wait a few minutes first, and why. The ssh-255 message still says retry now — a transport failure is not a verdict on the host, so there is nothing to roll off. This is not an automated reroll; gpu-tests.yml carries a TRIED machine_id list for that, and ci(bench-gpu): stop building on half-provisioned or bad-RAM boxes #939 scopes that work out.

Comments

Each of these was at odds with the code or with another comment:

• the gate blamed bad RAM while the CARGO_BUILD_JOBS comment blamed memory pressure for the same symptom. The latter now describes OOM as it actually presents (SIGKILL, or an allocation failure) and names jemalloc-sys's CARGO_MAKEFLAGS forwarding — which is the mechanism that makes the cap bind its nested make, verified in tikv-jemalloc-sys build.rs.
• dropped the unmeasured "~10 min dual build"; annotated the pre-existing "3 min 56 s" ETA reference as a pre-cap measurement that CARGO_BUILD_JOBS=8 will raise.
• the no-offer error and the env header now list reliability, gpu_frac and cuda_max_good, which they had drifted from.
• the gate now states its own scope: it does not exercise /opt/lambda-vm-sysroot, and a 1 s compile surfaces marginal RAM only sometimes. It catches a missing or half-installed toolchain every time, which is the real win.

Verification

actionlint (with shellcheck) clean; bash -n clean on all 10 run blocks; the exit-code matrix above and the tmpdir cleanup were both run against the extracted gate body, and the PR-comment rendering was checked through the workflow's own JS.

Not verified — needs a Vast API key and a live box: whether reliability>=0.95 leaves a non-empty pool, and the real -j8 build wall. Note also that /bench-gpu cannot exercise any of this pre-merge, since issue_comment loads the workflow definition from the default branch.