[ashhart]

Pull requests already restore main's newest build cache, but main itself built from nothing on every push. During a landing burst its saves fell several commits behind, and one shared-source commit in between undid most of a pull request's reuse.

What changes

• Main reuses its cache. The zig and zig-windows jobs on main restore main's newest cache, like a pull request, and save it again. So each push compiles and runs only what changed since the last save.
• zig_cache_restat --prune keeps the cache to about one build. It deletes the entries a checkout can't hit: an entry whose recorded file changed or can't be read, and any entry that uses a deleted entry's output folder. Without it, a cache that is restored and saved again keeps growing. All four restat steps pass --prune, including release-paths and macOS dev-tools, which already restored on main and were growing.
• A nightly run builds from nothing (03:23 UTC). It skips every restore, so something a reused pass could hide fails within a day: for example, a test that reads a file the build doesn't know about (build: the portable-names test runs every time, since a reused pass can't see a name added since #2311 fixed the one case found so far). It saves under a -nightly key, so it doesn't collide with the push run for the same commit. On the nightly run, release-paths checks all three platforms, as on main's pushes. The lean check is skipped because a scheduled run has no base to compare against.

If restat fails, the job just rebuilds more than it needs to. It never skips a check.

Tests

• tools/zig/zig_cache_restat_test.py with Zig 0.17.0: both tests pass. The new test_prune_keeps_one_build links a C object into the executable.
  • With nothing changed, pruning keeps every entry and all three steps stay cached.
  • After a change to the C file, all three steps miss and at least three entries are pruned along with their output folders. The number of output folders is the same after the rebuild, so the cache didn't grow.
• zig fmt --check is clean, the lean check finds nothing new, and the workflow parses.