What Problem This Solves

Node test shard jobs currently discard Vitest's filesystem module cache at job completion. Every shard therefore repeats cold transforms and imports for the shared source graph, increasing CI time and runner cost.

Why This Change Was Made

Persist the cache through Blacksmith sticky disks for trusted jobs and an actions/cache fallback elsewhere, using the same PR/protected trust scope as dependency caching. Keep shard planning unchanged. One deterministic matrix job commits the warm seed; every other job restores it read-only. Each concurrent Vitest worker receives a stable isolated directory, and the runner bounds the cache at 2 GiB by pruning oldest transform entries to 75% while preserving Vitest metadata.

User Impact

No product behavior changes. Maintainers and contributors get warmer Node shard startup across runs without concurrent cache-writer races or unbounded cache growth.

Evidence

Exact head: 0012e5ad6eff8285a8621ad6ebb60286476f2c5a

• CI run 29533745093: attempt 1 seeded the deterministic cache; same-head attempt 2 restored it. Both attempts passed every Node shard, lint, test types, workflow guards, Windows tests, and the aggregate CI gate.
• Representative Linux Node job wall times:

• Attempt 1 logs show compact-large-1 as the sole commit: on-change writer and all 25 other Linux shard jobs as commit: false readers. No ENOTEMPTY matches occurred in either attempt.
• Attempt 2 restored a 325,201,920-byte writer seed and added only 98,304 bytes before committing the refreshed snapshot.
• Blacksmith Testbox 29533278389: formatting, targeted scripts lint, workflow validation, full test-type gate, and 75 focused tests passed.
• Autoreview clean after three accepted improvements: avoid cross-lockfile restores, declare the new helper surface, and serialize sticky-disk writers.

AI-assisted: yes. I understand the cache isolation, persistence, invalidation, single-writer, and pruning behavior in this change.