lint: runtime-lazy-deps.test.ts "gating a flow in-process" runs on the default 5s timeout and flakes under load — its cold-load sibling already carries COLD_LOAD_TIMEOUT_MS #5421

packages/lint/src/runtime-lazy-deps.test.ts has two cases that both pay a
cold module load:

• the subprocess one ends }, COLD_LOAD_TIMEOUT_MS) (line 121);
• it('gating a flow in-process loads neither dep, and still finds the defect', …)
  (line 124) ends }) — vitest's default 5000 ms — even though its first act is
  await import('./runtime.js'), i.e. the same cold graph load, in-process.

Under a loaded machine (several agents' suites sharing one container) the
in-process one intermittently exceeds 5 s:

 × gating a flow in-process loads neither dep, and still finds the defect 5004ms
 FAIL  src/runtime-lazy-deps.test.ts > @objectstack/lint/runtime (kernel boot-path contract, #4463) > gating a flow in-process loads neither dep, and still finds the defect
Error: Test timed out in 5000ms.

Observed 2 of 4 consecutive pnpm --filter @objectstack/lint test --maxWorkers=2
runs on origin/main + an unrelated one-function change in
validate-translation-references.ts; the other 2 runs were fully green
(1202 passed). Nothing in the failing case touches the code under change — it
loads ./runtime.js and inspects require.cache.

Why it matters

It is a false red on whatever PR happens to run while the box is busy, on a test
whose actual claim (the boot path loads no source parser) is unaffected by wall
clock. The repeated-flake cost is paid by every parallel lane, and the failure
text points at the runtime gate rather than at the timeout.

Suggested fix

Give the in-process case the same explicit timeout its sibling already uses —
}, COLD_LOAD_TIMEOUT_MS) — so both cold-load cases state the same budget. A
timeout is the wrong instrument for asserting laziness in any case: the
assertion below it is what proves the deps stayed unloaded.

Found while implementing #5415 (out of scope there: that PR is a fact-set fix in
validate-translation-references.ts and does not touch the runtime entry).
Verified against origin/main d0856707f.