Make the scheduler delivery-bound assertion deterministic

[RenKoya1]

ScheduleDriver > bounds callback concurrency and immediately continues a due backlog asserts maxActiveCallbacks === DELIVERY_CONCURRENCY, but the observed peak is a function of timing rather than of the bound: each of the four runBounded lanes runs startHook -> authorizeObservation -> onSchedule over RPC, and the callback only holds for 10ms. When the lanes drift apart the peak lands below 4 even though the runner never exceeds it.

Reproducible on macOS/arm64 (M-series):

AssertionError: expected 3 to be 4 // Object.is equality
 ❯ __tests__/schedule-driver.test.ts:735:41

Rather than weaken the assertion to an upper bound — which would stop proving the bound is reached — this holds each callback until a full set of lanes has arrived, so the peak is the runner's bound and not RPC scheduling.

The batch of 20 delivers as exactly five full rounds of four, so the barrier waits on a count that is guaranteed to arrive and needs no timeout of its own; the tail round of one is excluded by the limit argument. The barrier is off by default, leaving every other test untouched.

Verification

Four consecutive runs of schedule-driver.test.ts, alternated on the same machine with nothing else running:

	run 1	run 2	run 3	run 4
main	fail	fail	pass	fail
this branch	pass	pass	pass	pass

pnpm test for the package is 102 passed / 3 skipped, and pnpm types:check is clean.

Unrelated, and untouched here: permanently fences mutations and cleans revoked storage in bounded alarm passes occasionally exceeds the 5s vitest timeout under CPU contention (it showed up on main run 4 above, and on this branch too when the whole monorepo suite runs in parallel). That is a separate load sensitivity, not the assertion this PR is about.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[RenKoya1]

I have read the CLA Document and I hereby sign the CLA