Run #4 showed cache-refresh-lock-process racing its own takeover window
even in the serial single-fork step (#904). The enforced signal stays
the main suite; the lock suite reports without gating until the race
semantics are settled.
The root vitest glob also matched app/renderer/*.test.tsx, whose jsdom
environment lives in app/node_modules and cannot resolve from the root
install; ERR_MODULE_NOT_FOUND took down the whole parallel step.
Implements the #898 proposal. The parallel-sensitive cache-refresh-lock
files run serially in their own step; everything else runs in the default
forks pool. Flag syntax verified locally against vitest 3.2.6.