fix(core): yield between plugin setup and full-scope cleanup operations - #55754

The fix comes from the zero-length sleep itself: the repro passes because each plugin gets its own macrotask turn. This module-level Semaphore.makeUnsafe(1) adds one process-wide lock shared by every location's setup and close. It makes each location's yield wait for all the others' timer turns, and it couples unrelated locations through module state, including across test layers. I don't see a concrete failure it prevents (a burst of locations resuming in one batch still yields each time). Could this be a plain Effect.sleep(0) (one constant for both paths), or could you describe the failure the lock avoids? The repo guidelines ask for that before adding complexity for speculative races.

Addressed in f3e6ab7, included in pushed head f97e165: one shared Effect.sleep(0), no process-wide semaphore. Existing lifecycle call sites and spans are unchanged. Bun 1.4.4 activate/close proofs pass (2/2); disabling each actual yield separately makes its corresponding test fail.

This adds a macrotask yield before every config plugin operation in resolve, including cheap remove and selector entries, which delays every reload a little. #55272 is about plugin setup and teardown, which plugin.ts now covers, and modules.load is already async. Unless you've measured starvation in this loop, I'd drop this change so the fix stays in the plugin lifecycle.

Removed the resolve-loop checkpoint and its import in f97e165. Cheap remove/select operations no longer pause; plugin setup/teardown yields remain unchanged. Core tsc build and fresh LSP diagnostics for all three edited files pass.

This file has 7 timing-based tests with busy loops, setInterval(0) and strict 'a tick happened between every pair' assertions. Several also re-test existing behaviour: cancellation and readiness holds, finalizer-defect ordering, and calling PluginScheduling.checkpoint directly. Could you cut it down to one small activate test and one close test that check a timer fires between CPU-heavy plugins? If the lock goes away (see the comment on scheduling.ts), the cross-location deadlock test isn't needed either.

Reduced to two activate/close tests in pushed head f97e165. Each arms a native timer inside the first CPU-heavy plugin and observes progress strictly between plugin work, retaining registration/LIFO order checks; no elapsed-time threshold or every-pair guarantee. Original baseline 7/7; new tests 2/2 on Bun 1.4.4. Disabling activate and close yields separately produces the respective failure, then both pass after restoration. Direct neighbours remain 35 pass/1 pre-existing failure: "applies organization integration changes to running external plugins" (error: pending), identical before/after. The broader plugin baseline timed out at 120 seconds; full-suite verification remains incomplete, not claimed green.