Run the Rust CI legs in parallel instead of in a line

[teddytennant]

A green run took 12m48s and 763s of it was one job. rust ran clippy, the suite, a release build, then clippy and the suite again under --features native, one after another, while everything else in the file had been finished for ten minutes. The macOS leg had the same shape: 105s of cargo check then 237s of cargo test, in a line, on the slowest runner here.

Measured on this branch: 768s to 371s wall clock, and both of the runs here were cold-cached against a warm baseline.

The split

rust became rust-lint, rust-test, rust-test-native, rust-release and a rust gate. suite keeps the two blocking cargo check steps on Darwin and suite-test takes the non-blocking suite.

The release build stops paying for LTO. [profile.release] is lto = true, codegen-units = 1, so a step whose only question is "does this compile with optimisations on" spent 334s linking 729 crates as one unit and then ran nothing. rust-cache drops the workspace crate's artifacts by design, so that link was paid in full on every run, cache hit or not. Overridden by environment, not by editing the profile, since release.yml builds ten assets from it unchanged. The tradeoff is the break only fat LTO finds, mostly duplicate symbols at link time; release.yml catches those before a tag publishes.

save-if on the build jobs the split touched. Six jobs across two platforms and two feature sets writing per-branch copies of the same 729 dependencies is how a 10GB cache budget becomes evictions. Pull requests read a cache and no longer write one, which also drops the ~25s save that would otherwise have been most of what the split cost.

Branch protection matches required checks by name, so "Rust checks" is now a gate job that needs the four legs and goes red when any of them does. No settings change. That adds two failure modes that look green: a leg nobody adds to the gate's needs, and a gate without if: always(), which GitHub skips rather than fails, leaving a PR waiting on a check that will never report. Both are asserted in Workflow invariants, along with the macOS suite still running cargo test somewhere now that it has left the job whose name is protected. Each of the five assertions was checked by mutating a copy of the file and confirming it fails.

Promoting the macOS suite to blocking is two edits now, not one: experimental: false on suite-test, and "macOS suite" added to the required checks. The note above the job says so and the summary step prints it. The experimental key left stranded in suite is removed, since a flag you can flip with no effect is worse than no flag.

The tests

Three tests were waiting on clocks nothing reads.

a_program_wedged_in_a_c_call_does_not_wedge_the_turn and cancelling_reaches_a_program_wedged_in_a_c_call both ran os.execute('sleep 30'). The turn returns in about 3s, which is what they assert, but the program is left to finish in its own time by design, so the test outlives it either way. They were the last two tests to finish in the entire run, which made them the floor.

Shortening the sleep alone would have gutted both, so the bound came down with it: at sleep 10 against the old 15s bound, a turn that waited for the program passes as happily as one the backstop saved. 6s sits between the backstop's grace period and the sleep. Checked by pushing BACKSTOP_GRACE to 8s, where both now fail at 8.3s and 9.0s and the old bound passed them.

a_sandboxed_script_is_bounded_in_time_and_memory is the third. Only the time half of that name is enforced. install_hook reads lua.used_memory(), mlua cannot install its allocator under luajit, and a 0 reading is skipped rather than tripped, so the memory branch cannot fire and the greedy script runs until the clock stops it. The || in the assertion is what hides it. Raising the budget to 60s made the test take 61s, where a working 64 MB cap would end a 1 MB-per-iteration script in under a second. Budget down to 3s with the finding written beside it. Making that bound real is a change to the sandbox and does not belong in this PR.

Numbers

Test execution, holding compile constant:

	before	after
Linux	49.30s	31.53s
Coverage job	49.90s	32.32s
macOS	94.02s	58.41s

The coverage job restored a full cache-key match on both runs, so that row is the clean one.

Job totals move around more than that: cold-build variance between the two runs here is about 15% either way, and Rust release build came in slower on the second run despite running no tests at all. The execution numbers are the ones that isolate the change.

[teddytennant]

Rebased onto e363a62 and added a rustfmt commit.

Rust lint went red on src/skills/mod.rs:188, which is not from this branch. e363a62 merged with cargo fmt --check already failing on that hunk, so main has been red since, and a PR is tested as base-merged-with-head. Second commit here is cargo fmt output on that one function, nothing else.

Worth a look separately: a required check went red on #45 and it merged anyway.