Diagnose unavailable standard-library capabilities for WebAssembly targets

## Problem

When a standard-library feature is unavailable on a WebAssembly target, module resolution currently reports it as though the library simply forgot to define a symbol.

For example, checking `examples/std/net_tcp.wave` for `wasm32-wasip1` reports that `std::sys::socket` has no symbol `listen`. WASI Preview 1 does not provide the native socket capability expected by that module, so the message points contributors in the wrong direction.

## Scope

- Distinguish an unavailable target capability/provider from an actually missing public symbol.
- Include the selected target and the importing high-level standard-library module in the diagnostic.
- Explain that native sockets are unavailable for the selected WASI contract.
- Coordinate with the target capability model tracked in related target/standard-library issues without making this diagnostic depend on a full capability-system redesign.
- Add resolver tests for supported and unsupported target/module combinations.

## Acceptance criteria

- Importing `std::net` on an unsupported WebAssembly target produces an actionable capability diagnostic.
- Genuine misspelled or private symbols retain their existing symbol-resolution diagnostics.
- Supported native targets are unaffected.

Start by reproducing the diagnostic with examples/std/net_tcp.wave for the wasm32-wasip1 target, then trace the resolver path that turns unavailable std::sys::socket capabilities into missing-symbol errors. Add resolver tests covering supported and unsupported target/module combinations, and verify that capability diagnostics are actionable while genuine missing or private symbols retain their existing messages.

Written by the indexing model from the issue text.