Possible regression in native crypto paths in componentize-js 0.20.0 due to preview1 random_get stubbing

Hi all,

@maxim-le and I hit a runtime trap in `componentize-js` 0.20.0 and wanted to share what we found in case we are understanding the behavior correctly. We may be missing context, so I’m filing this as a question / possible bug rather than assuming the current implementation is wrong.

## Symptom

We see traps like:

wasm trap: wasm `unreachable` instruction executed
0: ... !random_get

This happens for WebCrypto operations that appear to go through native crypto code, for example RSA private-key crypto.subtle.importKey("pkcs8", ...).

A simplified repro for us is:

```javascript
async function main() {
const pem = `-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----`;

const pemBody = pem
.replace(/-----BEGIN PRIVATE KEY-----/, "")
.replace(/-----END PRIVATE KEY-----/, "")
.replace(/[\r\n\s]/g, "");

const keyBytes = Uint8Array.from(atob(pemBody), c => c.charCodeAt(0));

const key = await crypto.subtle.importKey(
"pkcs8",
keyBytes.buffer,
{ name: "RSASSA-PKCS1-v1_5", hash: "SHA-256" },
false,
["sign"]
);

return { imported: true, type: key.type };
}
```

## What we found

The relevant code seems to be in:

`crates/spidermonkey-embedding-splicer/src/stub_wasi.rs`

```rust
fn stub_preview1(module: &mut Module) -> Result<()> {
// random comes from prevew2 only in StarlingMonkey
stub_import(module, PREVIEW1, "random_get", unreachable_stub)?;
Ok(())
}
```

The stub predates 0.20.0 by a long time. The main notable change between 0.19.3 (The previous version we used) and 0.20.0 relevant to this area appears to be the StarlingMonkey update in 499a888 ("Update StarlingMonkey (#325)"), which is consistent with the issue only becoming observable for us in 0.20.0.

## Current hypothesis

Our current guess is:

- componentize-js 0.20.0 bumped StarlingMonkey in a way that now exercises a native crypto / libc entropy path that actually reaches preview1 `random_get`
- once that path is exercised, the existing stub becomes visible as a trap

## What we verified locally

We tested a local patch that stops stubbing `random_get`, rebuilt the splicer artifacts, and reran the same RSA importKey case.

With that patch in place, the trap disappeared and the operation completed successfully.

Because of that, it seems plausible that preview1 `random_get` still needs to remain available for some native crypto paths, even if most JS-visible randomness is coming from preview2.

## Question

Does this sound like a real bug from your perspective, or is there intended behavior here that we are overlooking?

If useful, I’m happy to open a follow-up PR :)

Thanks.