test: a 60 s per-test limit on Windows, and the three tests that timed out split

[llima]

Summary

• On the Windows CI runners a test now and then runs at about 2.5 times its usual time. Three tests whose usual Windows time is 12–17 s passed the 30 s per-test limit that way in two days (runs 38323301390, 38378398875 and 38388376553 — the last one on main), each passing when run again. Measured over 33 Windows jobs: 3 failures in 18 node 22 jobs, none in 15 node 24 jobs, none on ubuntu.
• vitest.config.ts: the per-test limit is 60 s when the platform is win32 and stays 30 s elsewhere. maxWorkers: 6 is unchanged.
• The three tests that failed are split, every assertion kept:
  • drift-promote › 4. D4 — three cases → 4a, 4b, 4c (15 assertions before, 5 + 5 + 5 after);
  • cli › the three commands write nothing in the workspace or the Forge → one test per command (recipes, ingredients, targets): the same six invocations twice each and the --forge one once, each command's snapshot compared on its own;
  • golden-param › after both extractions every file of both workspaces is unchanged → one test per workspace, both still synced before the extractions.
• No file under src/, no version change: this publishes nothing.

Known and left as is: test/cli.test.ts has one older test with an explicit 30_000 limit, which is now half the Windows default; it was not among the failures. Each runCli child keeps its own 25 s limit, so a single stuck child still fails fast.

Test plan

• npm run typecheck, npm run build
• npx vitest run --exclude test/ci.test.ts --maxWorkers=6 on Linux — 101 files passed, 1 skipped; 2750 tests passed, 8 skipped
• Oracle: skipped — no fixture (no emitted byte is touched)
• CI 8/8 — the win32 arm of the config and the Windows times of the eight new tests can only be seen there