chore: serialise tests builds on arm64-linux-16

[ggreif]

Summary

Extends the same max_jobs=1 workaround used by gc-tests in #6009 to the tests matrix on arm64-linux-16. ubuntu-24-large keeps max-jobs=auto.

Why

tests (arm64-linux-16, release) and tests (arm64-linux-16, debug) have been OOM-killed by the runner whenever nix-build-uncached --max-jobs auto schedules three parallel ~3 GB derivation builds. Most recent observation: https://github.com/caffeinelabs/motoko/actions/runs/25409615273/job/74528169567 (initial CI on the pocket-ic bump PR #6088 — failure was unrelated to the bump itself).

Why max-jobs=1 (not 2)

We probed a higher ceiling but it's not stable enough to ship:

• PR [experiment] arm64-linux-16 max-jobs=2 #6090 ran gc-tests and tests at max-jobs=2 against a cache-busted test-runner and appeared to pass.
• PR chore: bump pocket-ic to release-2026-04-30_04-26-base #6088 with a different cache-buster (forcing a different content hash than [experiment] arm64-linux-16 max-jobs=2 #6090's, and therefore a real cold rebuild of the GC-variant derivations) hit OOM on gc-tests (arm64-linux-16, 2) after ~2.5 minutes:

  building 'test-drun-compacting-gc.drv'...
  building 'test-drun-generational-gc.drv'...
  Killed   nix-build-uncached -build-flags "--max-jobs 2"
  

  Run: https://github.com/caffeinelabs/motoko/actions/runs/25411132891/job/74532926605

The result depends on which derivations happen to be cachix-cached vs cold-rebuilt at any given moment. An asymmetric gc-tests=1, tests=2 configuration would also be brittle: a future test addition could shift the memory profile of release-systems-go and silently reintroduce OOMs. Going uniform max-jobs=1 is slower but stable.

Test plan

• CI green
• No tests (arm64-linux-16, *) OOM on the resulting run

🤖 Generated with Claude Code

[github-actions]

Comparing from 53943c3 to 677ddc3:
The produced WebAssembly code seems to be completely unchanged.
In terms of gas, no changes are observed in 5 tests.
In terms of size, no changes are observed in 5 tests.

[ggreif]

Bumped from max-jobs=1 to max-jobs=2 based on the experiment in PR #6090.

PR #6090 (cache-busted run_test.rs) ran the full tests matrix on arm64-linux-16 with max-jobs=2 against a cold rebuild of test-runner and every downstream test-* derivation. Every job passed:

Job	Duration
tests (arm64-linux-16, release)	18m26s
tests (arm64-linux-16, debug)	18m15s
gc-tests (arm64-linux-16, 2)	6m14s
common-tests (arm64-linux-16) (max-jobs=auto)	18m16s

So 2 parallel ~3 GB builds fit in 16 GB. Going to 3 was the original failure mode; 2 is the right ceiling.

[ggreif]

Update: gc-tests can't go to 2

PR #6088 with a fresh cache-buster (lib.rs instead of run_test.rs) forced a real cold rebuild of the GC-variant derivations and hit OOM:

building 'test-drun-compacting-gc.drv'...
building 'test-drun-generational-gc.drv'...
Killed   nix-build-uncached -build-flags "--max-jobs 2"

Run: https://github.com/caffeinelabs/motoko/actions/runs/25411132891/job/74532926605

PR #6090's gc-tests-at-2 only appeared to pass because cachix served the GC variants from a different content hash. Two RTS-variant builds in parallel (each ~3 GB) exceed the 16 GB runner.

So the matrix is asymmetric:

• gc-tests → max-jobs=1 (reverted)
• tests → max-jobs=2 (PR [experiment] arm64-linux-16 max-jobs=2 #6090 evidence holds; the release-systems-go constituent derivations are smaller than GC variants)

Awaiting tests (arm64, *) results from PR #6088 to confirm the asymmetric stance on tests.