Starting multiple interceptors breaks global restoration order #5

Summary

Each interceptor instance captures the current global fetch and XMLHttpRequest implementations when start() is called and restores those exact references on stop().

If multiple interceptor instances are started at the same time, stopping them out of order breaks interception state and can leave patched globals installed.

Reproduction

1. Start interceptor A
2. Start interceptor B
3. Perform a request
4. Stop interceptor A
5. Perform another request
6. Stop interceptor B

Current behavior

• Stopping A can disable B unexpectedly
• Stopping B afterward may fail to restore the native globals
• Global state depends on stop order instead of active interceptor count

Expected behavior

Multiple interceptor instances should either:

• compose safely, or
• be explicitly unsupported and guarded with a clear error

In either case, stopping one interceptor must not silently corrupt the global state for another.

Impact

This can cause hard-to-debug behavior in tests, browser extensions, and applications that create interceptor instances in different modules.

Suggested acceptance criteria

• Concurrent/nested interceptor instances have defined behavior
• stop() restores globals correctly in all supported lifecycle orders
• Tests cover at least the A-start, B-start, A-stop, B-stop sequence