SPZ / Gaussian Splatting loader unusable on Babylon Native (ES module import and ReadableStream)

## Summary

The Gaussian Splatting SPZ loader cannot run on Babylon Native at all. Two separate platform gaps are involved, and together they block **22 SPZ / Gaussian Splatting scenes** in the Babylon Native validation suite. Both reproduce identically on the WebGL/bgfx and WebGPU/Dawn backends, so this is not backend-specific.

This is a follow-up to BabylonJS/Babylon.js#18776, which made the first gap *report clearly* rather than silently misbehave. The underlying capability is still missing.

## Gap 1 — ES module `import` is not supported on native (19 scenes)

`GaussianSplattingFileLoader` loads the SPZ library by generating ES module source and handing it to `Tools._LoadScriptModuleAsync`:

```js
const module = await Tools._LoadScriptModuleAsync(
`import createSpzModule from '${spzLibraryUrl}';
const module = await createSpzModule();
const returnedValue = module;`
);
```

`_LoadScriptModuleAsync` appends its resolve shim and calls `Tools.LoadScript(source, undefined, onError, scriptId, /* useModule */ true)`.

On web, `_LoadScriptWeb(scriptUrl, onSuccess, onError, scriptId, useModule)` injects that source into a ``. On native, there is no DOM and no ES module loader, so `_LoadScriptNative` now (post-#18776) fails fast with:

> Loading a script as an ES module is not supported in Babylon Native

Before BabylonJS/Babylon.js#18776 the module source was passed to `Tools.LoadFile` as if it were a URL, which produced the confusing:

> Unable to open URL 'import createSpzModule from 'https://unpkg.com/@adobe/spz@0.2.0/dist/spz.js';

Either way the scene fails. The error is now honest, but the feature is still unavailable.

## Gap 2 — `ReadableStream` is not defined (3 scenes)

The SPZ "No WASM" decode path streams the response body, and Babylon Native's JS runtime has no `ReadableStream`:

> Unable to load from https://.../hornedlizard.spz: ReadableStream is not defined

Affects `Gaussian Splatting SPZ SH No WASM`, `Gaussian Splatting SPZ SH Order 4 No WASM`, and `Gaussian Splatting SPZ Detailed Splat No WASM`.

## Impact

Measured on the Babylon Native Playground validation catalog, running every test in its own process:

| Cause | Scenes |
|---|---:|
| ES module `import` unsupported | 19 |
| `ReadableStream` undefined | 3 |

All 22 fail on **both** the WebGL/bgfx and the WebGPU/Dawn backend. They are currently marked excluded in the Babylon Native test config, previously with a reason that misattributed the failure to XHR/streaming; that has now been corrected to point here.

## Possible directions

Listing options rather than proposing a specific design, since the right layer is not obvious:

1. **Provide a non-module entry point for the SPZ library**, or bundle/inline it, so the loader can use `Tools.LoadScript` without `useModule`. This is the smallest change and would unblock the 19 scenes without any runtime work.
2. **Support ES modules in the Babylon Native JS runtime.** V8 and JavaScriptCore both expose module-compilation APIs, but this is a substantial feature and would need a host-side module resolver.
3. **Avoid requiring `ReadableStream`** in the non-WASM decode path, or add a `ReadableStream` polyfill on the native side.

Happy to do the Babylon Native side of whichever direction you prefer. Option 1 looks like by far the best effort-to-value ratio if a non-module SPZ build is feasible.

## Repro

Any of the affected playgrounds under Babylon Native, e.g. `#XSNFXP#8` (`Gaussian Splatting SPZ Extensions`) with `spzLibraryUrl` set.

Start with GaussianSplattingFileLoader and Tools._LoadScriptModuleAsync/_LoadScriptNative, then run the affected Babylon Native validation scenes and inspect their test configuration. Clarify which module and stream approach maintainers want; done means the 22 SPZ/Gaussian Splatting scenes pass on both WebGL/bgfx and WebGPU/Dawn without the current exclusions.

Written by the indexing model from the issue text.