release: v0.3.0-alpha.23
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.