DnsResolver is not supported on WASI

`DnsResolver` and the `Dns.Resolve*` APIs are unsupported on WASI. The WASI build compiles `DnsResolverPal.Unsupported.cs`, so every query throws `PlatformNotSupportedException`, and the public surface is annotated with `[UnsupportedOSPlatform("wasi")]`.

Every other Unix-family platform (Linux, macOS, Android, iOS, tvOS, MacCatalyst, the BSDs) shares the managed stub resolver in `DnsResolverPal.Managed.cs` through the `-unix` target framework. WASI has its own TFM and was left out.

### Why it isn't simply enabled

Reusing the managed resolver on WASI runs into three separate problems:

1. **Sockets are available — this part is fine.** `SocketPal.Wasi.cs` shims both TCP and UDP over wasi-sockets, so `DnsSocket`'s reflection-based lookup of `System.Net.Sockets.Socket` would resolve and datagram queries are expressible.

2. **There is no resolver configuration to read.** WASI is capability-based with no ambient filesystem, so there is no `/etc/resolv.conf`. `ResolvConf.GetNameServers()` would return empty and `GetServers()` would fall back to `127.0.0.1:53`, which is not reachable. The parameterless `DnsResolver()` constructor and all the `Dns.Resolve*` statics (which use it) could not work; only a resolver constructed with an explicit `DnsResolverOptions.Servers` list would have a chance. This is the same gap tracked for Android in #132212.

3. **The synchronous API cannot work on a single thread.** `DnsSocket.Connect` blocks on `IAsyncResult.AsyncWaitHandle.WaitOne(timeout)`, and the synchronous query path uses blocking `Socket.Send`/`Socket.Receive`. WASI has no threads, so blocking the thread that drives the poll loop would deadlock. Only the asynchronous overloads look feasible, which would mean a partially supported surface.

On top of that, the host has to grant network capability (for example `wasmtime --wasi inherit-network`), so any test coverage needs harness configuration as well.

### What support would require

- A WASI-specific way to obtain DNS servers, or accepting that only explicitly configured servers are supported.
- Either an async-only surface on WASI, or reworking the synchronous path so it does not block the single thread.
- Enabling `DnsResolverTest` / `DnsResolverLoopbackTest` for WASI with network capability granted to the host.

### Current behavior

`DnsResolverTest.DnsResolver_UnsupportedPlatform_ThrowsPlatformNotSupported` asserts the `PlatformNotSupportedException` contract on Browser and WASI.

> [!NOTE]
> This issue was drafted with GitHub Copilot.

Read DnsResolverPal.Unsupported.cs, DnsResolverPal.Managed.cs, SocketPal.Wasi.cs, and the DnsResolverTest and DnsResolverLoopbackTest cases. Determine which resolver APIs can be supported on WASI given explicit servers and its single-threaded model, then run the relevant tests with network capability granted by the host. Done means the supported surface and platform annotations match the implemented behavior and coverage validates it.

Written by the indexing model from the issue text.