propagate the underlying std.http.Client.fetch error from HttpTransport.fetch and DidResolver.resolve instead of collapsing every transport-layer failure (DNS, connect, TLS) to error.RequestFailed / error.DidResolutionFailed. motivation: zlay 2026-04-08 incident — host_authority resolver pool hit ~99% rejection rate and the only error visible to the validator was error.DidResolutionFailed because both layers had been swallowed. we had to ship a workaround (keep_alive=false on the pool) without ever identifying the actual transport error. this fix unblocks the next investigation. regression test: src/internal/identity/did_resolver.zig asserts the returned error name is not the catch-all sentinel for a connect-refused case (did:web:127.0.0.1 → 127.0.0.1:443 unlistened). soft-breaking: the inferred error set on resolve/fetch widens. callers using `try` or `catch |err| { ... }` are unaffected. callers using an exhaustive switch on the prior narrow set would need to handle the additional variants — none in zat itself, and zlay's validator uses the catch-binding pattern.