[browser] Turn the >2GB memory test into an interop conformance test

[lewing]

Rewrites the AllocateLargeHeapThenInterop scenario into an actual conformance test for interop above the 2GB boundary.

Why

The wasm/JS boundary does not preserve signedness. A wasm i32 arrives in JavaScript as a signed number, so every pointer above 2GB shows up negative. The failure modes are mostly silent — a negative subarray start is clamped relative to the end of the heap, a negative HEAPU8 index yields undefined — so a scenario that only checks "a string JSImport still returns the right length" cannot detect them.

What

The scenario now asserts data integrity across the interop surface while every runtime allocation lives above 2GB:

• strings (short, non-ASCII, and a 1M char one), byte[] / int[] / double[] in both directions
• Span<byte> and ArraySegment<byte> memory views
• JSObject properties, exception propagation, Task<int>
• the JSExport direction (JS calling into managed with byte[]/string payloads)
• RandomNumberGenerator.Fill and globalization

It also reports the address of a pinned buffer and fails if allocations did not actually land above 2GB, so the test cannot silently stop testing what it is named after. The MemoryTests WBT additionally asserts that the run produced no jiterpreter code generation failed messages, which is how invalid pointer encoding surfaces in the trace compiler.

Validation

Ran the same test app against the shipped runtime packs with EmccMaximumHeapSize=4294901760 and 2.2GB / 3.6GB of heap wasted before startup:

runtime pack	result
11.0.0-preview.6 @ 2.2GB and 3.6GB	all checks pass, no jiterpreter errors
10.0.9 @ 2.2GB	RandomNumberGenerator.Fill silently returns an all-zero buffer; jiterpreter logs code generation failed: CompileError … extra bits in varint

So the new assertions catch the pre-#121221 behaviour rather than just passing everywhere.

Note

This pull request was authored with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR strengthens the existing “>2GB heap” wasm scenario by turning it into a more comprehensive interop conformance test, exercising multiple managed↔JS marshalling paths while allocations are intended to occur above the 2GB boundary.

Changes:

• Extend the WasmBasicTestApp MemoryTest scenario into an async test suite covering strings, arrays, memory views, JSObject interaction, exceptions, tasks, RNG, and globalization.
• Add richer JS-side imports/exports in main.js for validating both JSImport and JSExport integrity.
• Update the build test to assert the scenario actually completed successfully and that no jiterpreter “code generation failed” messages appeared.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/mono/wasm/Wasm.Build.Tests/MemoryTests.cs	Validates the scenario ran to completion and checks console output for jiterpreter compilation failures.
src/mono/wasm/testassets/WasmBasicTestApp/App/wwwroot/main.js	Expands module imports and adds JS-driven calls into managed exports for additional coverage.
src/mono/wasm/testassets/WasmBasicTestApp/App/MemoryTest.cs	Rewrites the scenario into a multi-check conformance suite (including new JSExport surface for the test).