[wasi] Stand up CoreCLR-WASI library tests

[lewing]

Follow-up to #130051 (CoreCLR-WASI bring-up). Once that PR lands with runtime-test coverage, the natural next milestone is standing up library tests on CoreCLR-WASI, mirroring the browser-CoreCLR LibraryTestsCoreCLR legs.

The Mono-WASI library-test infrastructure (src/libraries/sendtohelix-wasi.targets, src/mono/wasi/build/WasiApp.targets, Helix/wasmtime staging) is largely reusable — the gaps below are specific to swapping the Mono runtime pack for CoreCLR-WASI.

Gaps

1. Runtime pack

• WasiApp.targets today consumes Microsoft.NETCore.App.Runtime.wasi-wasm, which is Mono-only.
• Need a CoreCLR variant (or a RuntimeFlavor-conditional selector in the existing pack) so corerun.wasm + native libs land alongside CoreLib.
• Same story libs already had for browser-CoreCLR (Microsoft.NETCore.App.Runtime.browser-wasm.CoreCLR) — pattern is portable.

2. App-builder for CoreCLR-WASI

• WasiApp.targets produces a Mono-driver-shaped image (mono-wasi-driver.c linkage, ICU shims baked to Mono).
• CoreCLR-WASI needs the corerun + Bundle layout we already stage for runtime tests — either extend WasiApp.targets with a CoreCLR branch, or add a sibling WasiApp.CoreCLR.targets that reuses the Helix envelope but swaps the payload shape.
• The wasmtime-staging + PATH-prepend logic in helixpublishwitharcade.proj (from [wasm][wasi] CoreCLR wasi draft #130051) should hoist into a shared target.

3. Xunit test runner

• Browser LibraryTests uses Microsoft.DotNet.XHarness.TestRunners.Xunit via WasmTestRunner.
• Browser-CoreCLR LibraryTestsCoreCLR uses a slimmer runner project because the full XHarness runner had SDK deps that didn't fit CoreCLR wasm.
• WASI-CoreCLR wants the same slimmer runner, retargeted for wasi-wasm and callable from corerun.wasm --library <TestAssembly>.dll (or an equivalent entry-point wrapper).

4. P/Invoke surface expansion

• Runtime tests exercise a tiny p/invoke set. Library tests hit sockets, FS, TZ data, ICU, threading, timers, crypto, RNG, etc.
• Every one of those needs either a WASI resolver in the callhelpers-pinvoke tables or a PlatformNotSupportedException short-circuit.
• Mono-WASI already dealt with most of this — pal_wasi_missing.h and the WASI-side callhelpers will grow substantially.

5. Test exclusions

• The Mono-WASI test tree already carries [SkipOnPlatform(TestPlatforms.Wasi, …)] and IsWasiApplicable=false gating for chunks that fundamentally don't fit WASI (threading, subprocess, listening sockets, dup, mmap, etc.).
• CoreCLR-WASI inherits most of that gating but will surface new failures around finalization semantics, R2R behavior, Task.Run continuations, and other CoreCLR-specific corners. Fresh triage sweep will be needed.

6. CI wiring

• New template eng/pipelines/common/templates/wasi-wasm-coreclr-library-tests.yml mirroring wasm-coreclr-library-tests.yml.
• Add legs to runtime.yml, wire helix queues in helix-queues-setup.yml.
• Start with a smoke sub-leg (System.Runtime.Tests + System.Collections.Tests) analogous to LibraryTests_Smoke_AOT.

Suggested phasing

1. Smoke — land runtime pack + minimal app-builder + slim runner → single-library smoke leg (System.Runtime.Tests only). Forces items 1 + 2 + 3 to be real. Rough estimate: ~1–2 weeks.
2. Import Mono-WASI exclusion set wholesale into the CoreCLR-WASI test config.
3. Broaden coverage — enable one library at a time, file exclusions and p/invoke resolvers as we go, until parity with the browser-CoreCLR LibraryTestsCoreCLR leg. Rough estimate: ~1–2 months, mostly items 4 + 5.

Related:

• [wasm][wasi] CoreCLR wasi draft #130051 (CoreCLR-WASI runtime tests, precursor)
• [wasm][wasi] CoreCLR-WASI runtime-test exclusions tracking issue #130064 (known WASI-specific runtime test failures)

[dotnet-policy-service]

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

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.