wasi/http: error-code vocabulary parity with wasmtime — unsupported scheme, DNS payloads, catch-all buckets

[lannbot]

Found while comparing outbound wasi:http behavior against wasmtime-wasi-http 47.0.3 (src/p3/). Guests that switch on error-code variants get different answers for the same network condition on the two hosts.

Divergent buckets

Condition	polyengine	wasmtime
Unsupported scheme	internal-error("fetch cannot carry scheme ...") (wasi/src/http.ts:916-921)	HTTP-protocol-error (p3/request.rs:225, via hooks.is_supported_scheme)
DNS failure payload	DNS-error { rcode: none, info-code: none } (wasi/src/http.ts:157-159)	DNS-error { rcode: some("address not available"), info-code: some(0) } or some("invalid dns name") (p3/request.rs:288-293,333,340,359)
Unclassifiable connect error	internal-error(message) catch-all (wasi/src/http.ts:167)	connection-refused catch-all (p3/request.rs:342-345)
Unclassifiable protocol error	internal-error(message)	HTTP-protocol-error (p3/conv.rs hyper-error catch-all)

Neither side has clean provenance — we sniff fetch error prose (mapFetchError, wasi/src/http.ts:150-168), and wasmtime string-matches "failed to lookup address information" on io errors (p3/request.rs:335-341) — so exact parity is unattainable. But the fallback buckets are a choice, and ours leans on internal-error where wasmtime uses semantically-typed variants.

Suggested direction

• Unsupported scheme → HTTP-protocol-error is a one-line change and matches both wasmtime and the variant's plain meaning; the current internal-error reads as a host bug to the guest.
• Consider populating DNS-error.rcode with a coarse string when the sniff identifies DNS, for parity with wasmtime's payload shape (guests should not parse it, but some vs none is observable).
• The catch-all choice (internal-error(message) vs typed buckets) is defensible as-is — internal-error carries the prose, which is strictly more debuggable — but deserves a line in the recorded-divergences header (wasi/src/http.ts:40-60).