fix(browser): stop future requests after worker.stop

[felmonon]

Follow-up for #2650.

Addresses #2668 on top of the defineNetwork branch.

Summary

• install a local fetch/XHR passthrough interceptor when worker.stop() runs in Service Worker mode
• remove that passthrough interceptor on the next worker.start()
• keep already-started requests mockable while ensuring future requests bypass immediately
• add a browser regression for worker.stop(); fetch() in the same evaluation tick

Testing

• pnpm exec eslint src/browser/sources/service-worker-source.ts src/browser/utils/workerChannel.ts test/browser/msw-api/setup-worker/stop/in-flight-request.test.ts
• pnpm build
• pnpm test:browser -- test/browser/msw-api/setup-worker/stop test/browser/msw-api/setup-worker/stop.test.ts

[felmonon]

Follow-up: the earlier browser failure was due to lifecycle events still firing after worker.stop(). I fixed that in dc4a5b48 (fix(browser): preserve bypass lifecycle after stop), and the rerun is now green.

[kettanaito]

Hi, @felmonon. Thanks for an attempt on this, but this isn't the right solution for the problem.

We already handle in-flight requests though, and that doesn't change in the new architecture. The only existing issue is related to fake timers (see #2582) because they lock in in-flight resolution under a user action if they decide to mock timers.

Let me know if you have any thoughts on this pull request, otherwise I'm going to close it.

[felmonon]

Thanks for the clarification. That makes sense — I was treating this as a general future-request-after-stop regression, but if the remaining issue is specifically the fake-timer behavior tracked in #2582, then this patch is solving the wrong problem.

I don't have a stronger non-fake-timer repro to point to here, so I'm going to close this PR rather than push further in the wrong direction.