fix(test): cap local unit-test concurrency at 4 to avoid exhausting commit charge

[anhtahaylove]

Problem

The local test and test:unit scripts run with --test-concurrency=20 and --max-old-space-size=8192. Those multiply: up to 20 workers × 8 GB of heap reservation each. On a 32 GB developer machine with a ~53.8 GB commit limit, a full-suite run drives commit charge to the ceiling, and Windows starts refusing process creation — unrelated long-running Node processes die with 0xC0000142 (STATUS_DLL_INIT_FAILED, the usual symptom of a failed allocation at process start).

This is a local-only footgun. CI never hits it: ci.yml and quality.yml run test:unit:ci:shard, which already uses --test-concurrency=4 and spreads the suite across 8 GitHub-hosted runners with 16 GB each. The unsharded test/test:unit scripts are the ones a developer types by hand, and they are the only ones tuned for a machine that doesn't exist.

Fix

Set --test-concurrency=4 on both, matching test:unit:ci.

Also added the missing --test-force-exit to test. Without it the runner finishes every test and then hangs indefinitely on a live handle instead of exiting — test:unit and all the CI variants already pass this flag; test was the odd one out.

Verification

Full suite before and after, same machine, same base commit — the only difference is this package.json change:

	commit charge peak	wall time	pass	fail
--test-concurrency=20	ceiling (~53.8 GB), processes killed	—	—	—
--test-concurrency=4	37.8 GB (~16 GB headroom)	1418 s	38114	791

Sampled commit charge every 9 s across the run. No unrelated process died, and the local gateway on port 20128 stayed up throughout.

Results are unchanged: 413 of 415 distinct failing test names are identical across the two runs, differing by 2 in each direction — ordinary flakiness, not a behaviour change. (Those 791 failures are pre-existing on this base on Windows, mostly spawn/ENOENT from tooling this machine doesn't have installed. They are unrelated to this change.)

Wall time is not meaningfully worse: 1418 s here versus 1499 s for the pre-change baseline run. The 20-way setting was buying nothing — the suite is I/O-bound long before it is CPU-bound, and the oversubscription was pure memory pressure.

[anhtahaylove]

Self-review note, and a pre-existing bug this change does not fix.

Two things worth a maintainer'''s eye:

1. This PR also adds --test-force-exit to test. That is a behaviour change beyond what the title promises, so calling it out explicitly: without the flag the runner completes every test and then hangs indefinitely on a live handle instead of exiting (that is how I hit this in the first place). Every other runner — test:unit, test:unit:ci, :ci:shard, :fast, :shard:1/2 — already passes it; test was the only one that did not. Happy to split it into its own PR if you would rather keep this one purely about concurrency.

Worth noting the mild irony: --test-force-exit masks exactly the class of bug the rest of this audit is about (a live handle keeping the process alive). It is the right call for a test runner — a hang gives you no signal at all — but it does mean the suite cannot be used to detect leaks by watching whether it exits.

2. Pre-existing, untouched here: test is missing the serial quarantine step. test:unit, test:unit:ci, test:unit:fast and test:coverage:runner all end with && npm run test:unit:serial, and tests/unit/test-serial-quarantine.test.ts asserts exactly that for those four. test is absent from that list and does not chain the serial pass — so a developer typing plain npm test silently skips the four quarantined files from #6347 (glm-coding-plan-monthly-3580, quota-division-blocks, provider-health-autopilot, combo-health-autopilot).

Either test should chain the serial step like its siblings, or — if it is a deliberate legacy alias — it should be removed so nobody reaches for it. I have left it alone because it is out of scope here and the fix depends on which of those you intend. The quarantine guard still passes 4/4 with this PR applied.

[HouMinXi]

Thanks for capping local unit-test concurrency. I did not fold this into the local recut of release/v3.8.51.

Conflict was only package.json. Incoming dropped the local runner from 20 workers to 4; the recut keeps 20 so the deploy-tree gate finishes in one pass. No other files dropped.

Purpose of the recut: ship a production image, not change local test pacing. No objection to the change on developer laptops; it is not a production-image change, so it stays out of this recut.