Fix Firefox WASI module loading

[espmaniac]

Summary

• replace Emscripten ccall array marshalling with explicit _malloc, HEAPU8.set, and _free
• avoid decoding C strings directly from resizable WebAssembly memory
• detect supported guest entry points from the module exports
• launch application modules through app_main, WASI modules through _start, and conventional modules through main
• report the selected entry point in the site console

Root cause

Firefox rejects TextDecoder.decode() when Emscripten passes a view backed by resizable WebAssembly memory. The previous loader used ccall with the array argument type and used UTF8ToString for runtime errors, both of which can reach that incompatible decoding path.

Fix

Guest bytes are now copied explicitly into Emscripten memory before calling browser_task_create. Runtime error strings are copied into a normal non-resizable Uint8Array before decoding.

The loader also inspects WebAssembly exports and chooses the first supported entry point in this order:

1. app_main
2. _start
3. main

This allows wasi_puts.wasm from wasm-rtos-tests to use its correct _start export.

Validation

Do not merge until the JavaScript syntax check and complete Emscripten browser build succeed.