Fix main-loop immediate fallback isolation and cleanup

[patrickcorrigan]

EM_TIMING_SETIMMEDIATE's message fallback registers a global listener per module, but every listener recognizes the same setimmediate string. Exiting an instance leaves its listener installed. A later instance's message can therefore call setImmediates.shift()() on the exited instance's empty queue, throwing TypeError: setImmediates.shift(...) is not a function. The listener also retains the old module and its linear-memory buffer. Sequential module creation is sufficient to reproduce this; overlapping active instances are not required.

Use a private MessageChannel for each module's fallback, including when running in a Worker. Clear queued callbacks, detach the handler and close both ports on runtime exit and before invoking onAbort. Make disposal idempotent and prevent an unwinding runner from recreating the channel or scheduling more work. The native scheduler.postTask and Node setImmediate paths remain in place. This changes the main-loop timing fallback, not the separate emscripten_set_immediate API.

The regression exercises two separately evaluated modularized factories, repeated and concurrent instances, pause/resume, timing changes, cancel/restart, normal exit, forced exit, and abort, including an onAbort callback that throws. Abort coverage also runs without EXIT_RUNTIME. It checks remaining listeners/ports and unexpected errors. The existing polyfill test now actually hides scheduler, and also runs through PROXY_TO_PTHREAD.

Validation

Against upstream e34b2b50a1ffd755a4b746b85dbeeab6b255195e, using the exact SDK revision in test/emsdk_version.txt (83b1bdcbbb44ea970025bc08a5fb3c696c78e037) and Chromium 153.0.8010.36:

• Before: the new fallback lifetime test fails after the first exit with a remaining listener; the default/native case passes.
• After: all 13 focused browser tests pass, including Closure-optimized lifetime cases and the pthread fallback:

  test/runner 'browser.test_main_loop_scheduler_lifetime*' \
    'browser.test_emscripten_main_loop_setimmediate*' \
    browser.test_emscripten_main_loop_cancel_exit \
    browser.test_emscripten_main_loop_cancel_force_exit

• A separate local CDP garbage-collection check of the standalone fixture finds all ten modules and their buffers collect with both native scheduling and the fixed fallback. The unchanged fallback retains its first module. The portable regression asserts resource cleanup; it does not impose a cross-browser GC deadline. Its weak references remain available for GC diagnostics.
• The Node immediate-scheduler and unused-main-loop elimination checks pass. All 64 upstream code-size checks pass after updating the full-runtime dynamic-linking expectation (+467 bytes of JavaScript; WASM unchanged). Python lint and whitespace checks pass.

Actual Safari/iOS and full-suite validation remain outstanding. Minimal runtime has different shutdown semantics; a main-loop experiment on unchanged upstream also encountered an existing ABORT is not defined error. This PR does not claim to fix minimal-runtime lifecycle support.

Related reports and discussion

• The listener-leak comment in #20920 explicitly points out a separate window.addEventListener leak. This PR addresses that main-loop fallback; it does not claim to fix the already-addressed pthread mailbox issue itself.
• Maintainer guidance in #18080 explains that a modularized instance can be collected once references to it are gone. The persistent listener prevents that here.
• Discussion #22483 recommends MODULARIZE for independently compiled programs sharing a page. This is related usage context, not an earlier report of this exact defect.
• #26985 introduced the native scheduler.postTask path; the fallback still needs independent ownership and cleanup.