Mark WASM_BIGINT as deprecated (#27558)

With the minimum Safari version bumped to 15 in #27542, WebAssembly
BigInt integration (`WASM_BIGINT`) is now standard and enabled by
default across all supported engines. The only remaining use case
for disabling it is internally for `WASM2JS` (`-sWASM=0`).

Users should no longer set `-sWASM_BIGINT` directly, so mark
`WASM_BIGINT` as deprecated.

[docs] Remove old comment regarding nascent DOM Level 3 Events spec (#…

…27363)

This was added back in cef72b4.

Fix benchmarks after DEFAULT_TO_CXX change (#27487)

See #27469

Remove ./tools/scons/ from ruff exclusion list. NFC (#27423)

Fix config string parsing for windows pathnames (with backslashes) (#…

…27408)

By using `shlex.shlex(x, posix=True)` and clearing `lexer.escape`,
config
strings are parsed with POSIX quote handling while allowing Windows
paths to be specified with backslashes.

See: #27219

Update emsdk version used in testing (#27325)

This is an automatic change generated by tools/maint/rebaseline_tests.py
--bump-emsdk.

emsdk version updated: 99219dd9dec7558e4c8640b568ee54aebd409da1 =>
48c730101db0c5c74a0a1042ed21631370db9c86

This includes the following revisions:

```
- 48c73010 Roll llvm-project from 3a6048dbea15 to 2aab89554cbf (8 revisions)
- 45714672 Roll llvm-project from d6d0ccce19d1 to 3a6048dbea15 (3 revisions)
- b7ada761 Roll v8 from 0646faaada71 to 81b069e2bf3a (1 revision)
- 58e9c910 Roll llvm-project from 670e0a0c147a to d6d0ccce19d1 (10 revisions)
- 09875eb8 Roll llvm-project from e490b437555b to 670e0a0c147a (5 revisions)
- f0684759 Roll emscripten from 3af4cdc to bd5b72d (1 revision)
- a091b69d Roll llvm-project from e2223e665ecc to e490b437555b (12 revisions)
- cf339f1c Roll llvm-project from a83ec0fb845e to e2223e665ecc (6 revisions)
```

Full log:
https://chromium.googlesource.com/emscripten-releases/+log/99219dd9dec7558e4c8640b568ee54aebd409da1..48c730101db0c5c74a0a1042ed21631370db9c86

Co-authored-by: emscripten-bot <emscripten-bot@users.noreply.github.com>

Set GROWABLE_ARRAYBUFFERS=1 by default (#27212)

This means we auto-detect and use the `toResizeableBuffer` method in
cases
where it is useful.

By default this still has no effect because `ALLOW_MEMORY_GROWTH` is not
enabled by default.

See `TEXTDECODER` for similar ternary setting where we default to 1.

Add `CROSS_ORIGIN_STORAGE` link flag (#27066)

Integrates the [WICG Cross-Origin Storage
API](https://github.com/WICG/cross-origin-storage) into Emscripten's
standard Wasm loading path as a progressive enhancement.

When `-sCROSS_ORIGIN_STORAGE=1` is set at link time, Emscripten computes
the SHA-256 hash of the final `.wasm` binary and embeds it as a
build-time constant. At runtime the generated JavaScript tries to
retrieve the module from the cross-origin cache before falling back to
the normal `fetch()` / `WebAssembly.instantiateStreaming()` path, so
pages always load regardless of browser support.

## New settings

* `-sCROSS_ORIGIN_STORAGE=1` — enables the feature (Web target only,
disabled by default).
* `-sCROSS_ORIGIN_STORAGE_ORIGINS` — controls which origins can read the
cached file: `'*'` (default, globally available), an explicit HTTPS
origin list, or `[]` (same-site only).

Because no browser ships the API natively yet, testing requires the [COS
Chrome
extension](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
([source](https://github.com/web-ai-community/cross-origin-storage-extension)),
which polyfills `navigator.crossOriginStorage` on every page.

## Example 

### Without the COS API

Loading goes through the normal `fetch()` /
`WebAssembly.instantiateStreaming()` path:

<img width="1597" height="453" alt="Screenshot 2026-06-08 at 12 26 41"
src="https://github.com/user-attachments/assets/73a5e4f6-af27-4634-b60d-e7882d26e04f"
/>

### With the COS API

Now with the [COS Chrome
extension](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
installed, see its popup window for details.

#### First time load

Loading goes through the normal `fetch()` /
`WebAssembly.instantiateStreaming()` path, but the resource is stored in
COS for the next time:

<img width="1772" height="584" alt="Screenshot 2026-06-08 at 12 27 41"
src="https://github.com/user-attachments/assets/58b4c14c-3230-4bf5-9841-2b2e3dd58943"
/>

#### Repeated load

Loading now goes through the COS path:

<img width="1772" height="892" alt="Screenshot 2026-06-08 at 12 29 34"
src="https://github.com/user-attachments/assets/00839106-066c-4d82-a617-ecc7017f0514"
/>

#### Loading on a different origin

Loading now goes through the COS path and the resource is shared across
origins:

<img width="1772" height="892" alt="Screenshot 2026-06-08 at 12 31 02"
src="https://github.com/user-attachments/assets/af22fb9b-8602-43a7-86b3-6bbb43cc6db8"
/>

---------

Co-authored-by: Sam Clegg <sbc@chromium.org>

[deps]: Bump google-closure-compiler from 20260519.0.0 to 20260527.0.0 (

#26997)

Bumps the production-dependencies group with 1 update in the /
directory:
[google-closure-compiler](https://github.com/ChadKillingsworth/closure-compiler-npm).

Updates `google-closure-compiler` from 20260519.0.0 to 20260527.0.0

Fix an issue if user passes a relative path to Python (#26799)

Fix an issue if user passes a relative path to Python, and some system
cache libraries need rebuilding. Emcc tool would spawn sub-emcc tools to
rebuild the cache, with different CWD, resulting in the relative path
lookups pointing to the wrong relative directories. To fix the issue,
normalize the relative tool paths first.

<img width="2380" height="992" alt="image"
src="https://github.com/user-attachments/assets/e22b71c0-b73e-411c-9ef5-f51a890f01aa"
/>