[wasm][wasi] CoreCLR-WASI follow-up TODOs from #130051 (PERFTRACING, exit-code marker, getexepath synth)

Tracks three deferred items called out during review of #130051 ([wasm][wasi] CoreCLR wasi onboarding). Each is an intentional stopgap with a clear removal/replacement condition; grouping them here so the corresponding review threads can be resolved with a concrete link. Related umbrella (test exclusions): #130064.

### 1. Wire WASI PERFTRACING and re-enable the diagnostics server PAL

`src/coreclr/debug/debug-pal/CMakeLists.txt`

```cmake
if (NOT CLR_CMAKE_TARGET_WASI)
# ds-ipc-pal-socket.c needs UNIX/TCP sockets; re-enable once
# WASI PERFTRACING is wired.
set(DEBUG_PAL_REFEREENCE_DIAGNOSTICSERVER ON)
endif()
```

`DEBUG_PAL_REFEREENCE_DIAGNOSTICSERVER` is currently forced off for WASI because `ds-ipc-pal-socket.c` depends on UNIX/TCP sockets that are not yet available. Re-enable once WASI PERFTRACING transport is wired up.

### 2. Remove the "WASM EXIT " stderr marker once `exit-with-code` is usable

`src/coreclr/hosts/corerun/corerun.cpp`

```cpp
// ... when DOTNET_WASI_PRINT_EXIT_CODE=1, emit a "WASM EXIT " marker on
// stderr matching Mono (src/mono/wasi/runtime/main.c); the WASI launcher in
// src/tests/Common/CLRTest.Execute.Bash.targets recovers the value from that.
```

The current toolchain collapses any non-zero `Main` return to host exit 1, so we emit a text marker that the test launcher parses. `wasi:cli/exit` already defines `exit-with-code: func(status-code: u8)`, but it is gated `@unstable(feature = cli-exit-with-code)` in wasi-cli 0.2.x ([wit/exit.wit](https://github.com/WebAssembly/wasi-cli/blob/main/wit/exit.wit)). Once that feature stabilizes and the toolchain/host (wasi-libc, wasi-sdk, wasmtime) expose it so a non-zero code can be reported directly, this marker and the matching parser in `CLRTest.Execute.Bash.targets` can be removed.

### 3. Replace the CORE_ROOT-based executable-path synthesis in getexepath

`src/native/minipal/getexepath.h`

```c
#elif defined(TARGET_WASI)
// WASI has no /proc, no AT_EXECFN, and argv[0] is unreliable (often "/").
// corerun.wasm is launched with the CORE_ROOT env var set to the directory
// that holds CoreCLR ... The PAL only needs a path whose dirname is that
// directory, so synthesize one here.
const char* coreRoot = getenv("CORE_ROOT");
...
return result; // /corerun
```

This synthesizes a fake `/corerun` path because WASI exposes no reliable way to get the executable path. It works for the test host (which always sets `CORE_ROOT`) but is not a general host solution. Replace with a proper mechanism when WASI/wasi-libc exposes the executable path, or when a non-test host needs it.

---

Refs: #130051

> [!NOTE]
> This issue was drafted by GitHub Copilot on behalf of the author.

Start with src/coreclr/debug/debug-pal/CMakeLists.txt, src/coreclr/hosts/corerun/corerun.cpp, and src/native/minipal/getexepath.h, then inspect the WASI launcher in src/tests/Common/CLRTest.Execute.Bash.targets and the related review in #130051. Verify the available WASI exit and executable-path mechanisms before changing the three stopgaps; done means diagnostics, exit codes, and executable paths no longer depend on their temporary workarounds.

Written by the indexing model from the issue text.