Release runtime keepalive in emscripten_clear_timeout and make clear_timeout/clear_immediate idempotent

[guybedford]

Resolves #23763.

This fixes a runtime keepalive leak in emscripten_clear_timeout and makes emscripten_clear_timeout / emscripten_clear_immediate safe to call for ids that have already fired.

emscripten_set_timeout goes through safeSetTimeout, which does runtimeKeepalivePush() and pops in the fire wrapper. emscripten_clear_timeout was aliased straight to clearTimeout, so clearing a pending timer leaked one keepalive forever: with EXIT_RUNTIME=1 the runtime never exits after main returns (no atexit handlers run, emscripten_runtime_keepalive_check() stays true). emscripten_clear_immediate had the mirror bug: it popped unconditionally, so clearing an already-fired immediate double-popped the counter.

• safeSetTimeout now follows the setImmediateWrapped.mapping pattern: it returns an i32 index into safeSetTimeout.mapping holding the native handle, and the fire wrapper clears the slot before popping the keepalive. Ids start at 1 so, like setTimeout, they are never zero.
• New $safeClearTimeout(id) pops and clears only if the slot is still live, otherwise it is a no-op. emscripten_clear_timeout aliases it, which also removes the AUDIO_WORKLET special case. SDL_PauseAudio uses it too instead of a raw clearTimeout, which had the same leak.
• emClearImmediate (both the setImmediate and postMessage variants) reports whether the immediate was still pending, and emscripten_clear_immediate pops only in that case.

Tests: other.test_emscripten_clear_timeout_{fires,cleared,idempotent,immediate} cover clearing a pending timeout (runtime exits from main immediately with atexit running), clearing the same id twice and clearing an id after it fired while another pending timer keeps the runtime alive, the existing set-then-fire behaviour, and the same idempotency for immediates. Three of the four fail without the fix.

Made with AI assistance under my review