Seed the scheduler revocation fixture in one Durable Object invocation

[RenKoya1]

ScheduleDriver > permanently fences mutations and cleans revoked storage in bounded alarm passes has to leave behind more rows than a single #cleanupRevokedAccount pass clears, so it enables sixty schedules first. It did that as sixty separate runInDurableObject round-trips, and that setup is where nearly all of the test's runtime went.

That put it uncomfortably close to vitest's 5s default: on an idle machine it measured 2.9s–4.3s, and under the CPU contention of the full pnpm -r test it exceeded the timeout outright.

Enabling them inside a single invocation keeps the test identical in substance — it is still the real enable() path, so every schedule still gets its caps: row and the cleanup assertions are untouched — while removing the round-trip cost.

Verification

Duration of that test within a full schedule-driver.test.ts run, three runs each, same machine, nothing else running:

	run 1	run 2	run 3
main	2939ms	3156ms	4310ms
this branch	1013ms	1091ms	1016ms

pnpm exec tsc --noEmit is clean. The one remaining failure in this file on this branch is bounds callback concurrency and immediately continues a due backlog, which is a separate assertion flake addressed in #103; the two branches touch different regions of the file and merge cleanly.

[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