Cut CI time by splitting the build job and fixing the cache #352

Priority

Medium — should be addressed soon

User story / Problem statement

The build job runs every check in one serial job and takes about 12.5 minutes; with the harness wind-down (#344) it passes 13. Measured on run 40351260193 (#347):

The cache rarely helps:

• CI runs on push only for main, so no cache exists for feedback.
• Each pull request saves its own cache of about 1 GB under refs/pull/<n>/merge. Other pull requests cannot read it, and the repository's 10 GB limit evicts these caches quickly.
• The key has no fallback, so any change to Cargo.lock misses.

As a contributor, I want CI to report in about half the time, so a stack of pull requests and its merge-forwards do not wait in line.

Expected outcome

CI reports in about 7 minutes with a warm cache and runs the same checks as today. A pull request that only changes docs skips the Rust and network jobs.

Acceptance criteria

• The build job is split into jobs that run in parallel: JS checks; Rust tests (unit and Wasm upgrade); and the network job (local network, Scaffold build, app build, smoke tests, harness)
• Pull requests restore the cargo cache: CI also runs on push to feedback, the key has a restore-keys fallback, and the cache holds dependencies rather than the whole target/ (for example with Swatinem/rust-cache)
• The network job starts the local network first and builds while it boots
• A pull request that only changes docs skips the Rust and network jobs, and the required checks still pass
• A new push cancels the older run of the same branch (concurrency with cancel-in-progress)
• Playwright's browser is cached by its version
• Every third-party action is pinned by commit SHA, like the rest of the workflow
• The pull request states the before and after times of one run

Alternatives considered

• Larger runners: faster Rust builds, but they cost money. The repository is public, so ubuntu-latest already has 4 cores.
• Splitting the guards suite (120 s) across jobs, each with its own local network. It is the biggest single step left, but each job pays the network setup again. Worth a follow-up once the split above lands.

Technical notes

• Start after ci: build the app against the contracts the branch deploys #349, ci: run a wind-down on a throwaway vault #344 and ci: check formatting, lints and dependencies #347 merge into feedback: all three edit .github/workflows/build.yml.
• The contracts are built for Wasm three times: by the upgrade tests, by Scaffold, and by the short wind-down build in ci: run a wind-down on a throwaway vault #344. Sharing one target directory, or passing the built Wasm between jobs, may save more.
• For docs-only pull requests, a first job can run a paths filter, and the heavy jobs skip with a job-level if. A skipped job reports success, so branch protection does not wait on it.