fix: lock onmessage to prevent duplicate message handlers

[jiangheng90]

Problem

wasm-bindgen's mod.default() sets self.onmessage during init.
When wasmworker uses addEventListener('message', ...) for task dispatch,
both handlers fire. The wasm-bindgen handler cannot parse wasmworker's
message format, causing Cannot read properties of undefined (reading 'length').

Fix

Lock the onmessage setter via Object.defineProperty with a no-op
setter after mod.default() completes. Applied to both WORKER_JS
and WORKER_JS_WITH_PRECOMPILED.

Testing

Verified with 4-worker pool running mixed #[webworker_fn] and
#[webworker_channel_fn] tasks. No errors.

[paberr]

Thanks for the report and the fix. The placement (after mod.default(), before task dispatch, in both blobs) looks correct. Inline comments below. One more ask:

Could you add a regression test in test/, e.g., a #[wasm_bindgen(start)] fn that registers a conflicting onmessage, asserting tasks still complete?

Longer term I would move task dispatch onto a dedicated MessageChannel port, which
would make wasmworker immune to module handlers in both directions. That would be the more robust fix.

[jiangheng90]

"This issue arose about a month ago when I was trying to integrate my own crate, draco_decoder use in project with thread pool of wasmworker i. However, the issue is quite old now, and I no longer have a code environment that can reproduce it. Moreover, I had made a series of changes to the JavaScript implementation of draco_decoder before, but those have now been reverted. Currently, I am still maintaining the worker creation on the JavaScript side of draco_decoder myself. So I'm very sorry, but this commit was also written by AI, and I'm not sure if it will be of any use."

[paberr]

Thanks @jiangheng90. I'll have another look this week!

[paberr]

dedicated message port looks good