[tomayac]

With -sCROSS_ORIGIN_STORAGE, instantiateAsync() returned the promise from cosInstantiateStream() without awaiting it. A compile failure on the cache-hit or cache-miss path therefore skipped the surrounding catch and rejected module instantiation, while the comments say it falls through to the standard path. One realistic trigger is a server that answers the .wasm URL with an HTML fallback page.

This change awaits both calls, so the failure reaches the fallback. A hit with bad bytes now refetches from the network, and a failed miss falls through to the standard streaming path.

The new browser.test_cross_origin_storage_bad_hit test stubs navigator.crossOriginStorage to return bytes that do not compile and to refuse writes, so it runs without the COS extension. I checked the same behavior against a 6.0.13 build of SQLite Wasm in Chromium: without the change, init rejects with CompileError; with it, the module loads from the network.

[gemini-code-assist]

Code Review

This pull request ensures that when using -sCROSS_ORIGIN_STORAGE, a Wasm file that fails to compile on the cache-hit or cache-miss path correctly falls through to the standard loading path. This is implemented by adding await to the cosInstantiateStream calls inside the try-catch blocks in src/preamble.js, ensuring compilation errors are caught. A new browser test, test_cross_origin_storage_bad_hit, has been added to verify this fallback behavior. There are no review comments, so I have no feedback to provide.