ci: restore-keys for the LLBC caches, and two jobs' worth of duplicated work removed - #1347

Three CI changes, measured rather than guessed. Baseline is run 32172685070
(all jobs green): 373 min of wall across 13 jobs, or 1363 min once the
macOS ×10 and Windows ×2 multipliers are applied, with the critical path at
78 min (prepare Charon/LLBC (ubuntu) 11.6 → pyre/check.py (ubuntu) 66.7).

1. The per-crate LLBC caches get a restore-keys fallback

The four entries carried an exact key and nothing else, so a miss restored
nothing. The key is the wide digest — Compute LLBC fingerprints runs
before any .readfiles exists, so source= falls back to the whole cargo
closure there, and one edit anywhere misses all four crates. Every run
re-extracted the whole set: 10.6 min ubuntu, 19.5 windows, 22.3 macOS.

This is safe because the key is only a hint. extract-llbc.py recomputes each
crate's stamp against the current tree — narrowing source= through the
restored .readfiles — and compares it to the restored stamp as exact text
over source=/closure=/external=/charon=/layout_flags=. A restored
artefact that does not match is re-extracted, so a stale restore costs a
download and cannot reach the artefact.

Verified locally:

• nothing changed → all four print skipping … (fingerprint unchanged) in 2s
• a comment appended to pyre/pyre-jit/src/call_jit.rs, which is in pyre-jit's
  readfiles and no other crate's → pyre-jit alone re-extracts, the other
  three skip

Expected saving, from measured per-crate extraction times against the share of
the last 60 commits on main that touch no file in each crate's readfiles:

All four must re-extract on 8% of commits; weighting share by hit rate puts the
expected saving near half of each Extract step.

2. The pyre-wasm web-binding build moves off the check.py leg

It sat ahead of Run pyre/check.py on the premise that building
--features web first would leave check.py's later --features wasm-host
build sharing compiled dependencies. Measured on a cold target dir:

The sharing is real and worth 50 seconds for 6 minutes spent — half the
graph still recompiles because check.py sets
RUSTFLAGS='-C link-arg=--export-table -C link-arg=--growable-table --cfg getrandom_backend="custom"'
and the web step sets none. On the ubuntu runner the step measures 11.7 min.

The build itself is unchanged — this keeps the full cargo build compile
signal, it just runs somewhere cheaper. sandbox-build already carries the
checkout, toolchain, Cargo cache and prepared Charon/LLBC set it needs, runs on
the same image, and at 15.4 min sits far off the critical path. It goes first in
that job so the signal still arrives early. Nothing executes the artefact either
way; check.py writes its own pyre_wasm.wasm. The job is renamed
sandbox e2e + wasm web build (ubuntu-24.04).

3. The CPython suite becomes trailing steps of cargo test (ubuntu-24.04)

cpython-tests repeated the checkout, toolchain install, Cargo cache restore
and Charon/LLBC download that cargo-test-linux already does on the same runner
image, and needed the same prepared artefacts. Its two steps move into that
job's shared step anchor under runner.os == 'Linux', and the job is deleted.

Both carry !cancelled(), so a failing cargo pass above them cannot suppress
the suite the way plain step ordering would — as separate jobs neither could
hide the other. cargo-test-linux takes the deleted job's timeout-minutes,
raised to 90 to cover the work now in it.

This one is the smallest of the three: it recovers about 1.4 min of duplicated
setup and one runner slot. It does not remove the release pyre-dynasm
build, which check.py still does separately.

Expected effect

What to watch on the first run

sandbox-build has no Free up runner disk space step and now links a wasm32
release target on top of a native release pyre and a release e2e test binary.
If disk runs out there, that step can be copied across from cargo-test-linux.

Checked and deliberately not changed

• Extracting LLBC once and fanning it out to the other hosts is not possible.
  Diffing llbc-Linux-X64 against llbc-macOS-ARM64 from one run,
  pyre-interpreter.ullbc.readfiles differs: macOS lists interp_kevent.rs,
  interp_kqueue.rs and select/mod.rs, which Linux never compiles. The
  artefacts describe different sets of functions, so the per-OS artefact naming
  is load-bearing. Only the *.wasm32-unknown-unknown.layouts.ullbc sidecars
  are byte-identical across hosts.
• rust-cache is healthy. cargo test (ubuntu-24.04) on main reports
  Restored from cache key "v0-rust-X64-Linux-x64-…" full match: true,
  Cache Size: ~2628 MB. The 0.00m Post Run steps are an exact hit correctly
  skipping the save, not a broken cache.
• Cutting benchmark subprocess spawns buys nothing. From the per-line
  timestamps in the check.py job logs, spawn overhead outside the measured
  seconds is 1.9 min on ubuntu (0.05s across 2149 spawns), 2.6 on windows, 1.6
  on macOS.
• Skipping cargo test when no Rust changed would never fire — 0 of the
  last 40 commits on main leave *.rs/Cargo.toml/Cargo.lock untouched.

Summary by CodeRabbit

• Bug Fixes

  • Improved build-cache recovery so stale artifacts can be revalidated and selectively restored.
  • Added extended Linux test timeouts and conditional support for CPython 3.14.

• Tests

  • Consolidated CPython testing with Linux cargo tests while preserving independent execution.
  • Included the WebAssembly web build in sandbox validation.

• Documentation

  • Updated testing documentation to reflect the current CI workflow and job locations.