[Sequela02]

Part 7 of the move to Effect became fixing the places in the engine's loop that do not hear a stop (debated with GPT-6 Astra and GPT-6.1 Sol, and measured; the owner approved fixing them directly rather than moving loop.ts to Effect). This is the request's base. Found by Sol reading the code; reproduced and fixed by Claude.

Defect

Before a request runs, the loop records its base (captureBase), and in a folder outside Git that takes a snapshot under the snapshot store's lock, waiting up to 30 s for another session's snapshot. None of it heard the stop, and abort() awaits the run, so stopping a request while the store was held waited out the 30 s. Reproduced on dev with the real path: the test holds the store's lock, starts a request in a folder outside Git and stops it; abort() returned after 30.2 s.

Change

• withLockWhile takes an optional signal: a stop ends the wait for the lock (refused as the lock being held). Work that already holds the lock runs to its end, so the lock is never released under it.
• takeSnapshot takes the signal: it does not wait for the store, nor start a Git step, once the run is stopped, and returns "the run was stopped before the snapshot was taken". A Git step under way is short and runs to its end: gitOutput already explains why Git is not killed (on Windows git can be a launcher, and killing it leaves Git running).
• captureBase and the loop pass the run's signal through; HostParts.withLockWhile and LoopOptions.captureBase take it.

Checks

• New test in packages/core/tests/snapshot.test.ts: the store held by another, a request started and stopped; it ends aborted within 5 s, with the base's unit refused for the stop. On dev it waits 30 s and fails; with the change it passes.
• bun run check locally (Windows): Tests 264 passed (264); 332 pass; 3 skip; Over budget: shellRssBytes: 120913920 is over its limit of 115000000.