[wasi] Stand up CoreCLR-WASI library tests

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 #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 .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:
- #130051 (CoreCLR-WASI runtime tests, precursor)
- #130064 (known WASI-specific runtime test failures)

Start with src/libraries/sendtohelix-wasi.targets, src/mono/wasi/build/WasiApp.targets, and the CoreCLR browser library-test setup referenced in the issue. Then read the runtime-test changes from #130051 and the existing pipeline files, including runtime.yml and helix-queues-setup.yml. Done means a smoke System.Runtime.Tests leg runs on CoreCLR-WASI with the required runner, staging, and CI wiring; broader coverage is a separate follow-up.

Written by the indexing model from the issue text.