#1371 HTTP egress does not honor Happy Eyeballs (RFC 8305) on dual-stack DNS responses — IPv6 blackhole hangs the request

Summary

When a model's baseUrl returns both A and AAAA records, swamp's underlying HTTP client (Deno fetch) attempts only the IPv6 address and hangs until timeout, instead of racing IPv4 in parallel per RFC 8305 (Happy Eyeballs v2).

Repro

Observed against a dual-stack HTTPS endpoint where one address family (IPv6) was blackholed from the client egress:

# Default: hangs to timeout, fails
curl --max-time 10 https://<dual-stack-host>/
# → curl: (28) Connection timed out
# verbose trace shows only "Trying <ipv6-addr>:443..."

# Forced IPv4: succeeds
curl -4 --max-time 10 https://<dual-stack-host>/
# → HTTP 200/302 in <1s

Same behavior through a swamp model method targeting the same host:

swamp model method run <model> <method>
# → "The operation was aborted due to timeout" after 30s

Expected

Per RFC 8305, the client should:

1. Issue A and AAAA queries in parallel
2. After ~250ms with no response from the first address family, start connections to the other family in parallel
3. Use whichever connects first

Actual

Client picks IPv6 (AAAA), connects, waits for the full timeout, fails. IPv4 is never attempted.

Impact

Any swamp model whose baseUrl resolves dual-stack is unusable from any egress where one address family is blackholed — a real-world scenario on misconfigured networks, partial IPv6 deployments, and hosts with broken IPv6 peers. This silently breaks method execution (30s hang → timeout) with no indication the root cause is address-family selection.

Environment

• swamp 20260720.142822.0-sha.0caa5556
• Linux (glibc resolver)

Suggested fix

• Verify Deno's fetch implementation enables happy eyeballs (it may not — check Deno's network stack)
• Consider allowing models to pass an ipFamily / preferIPv4 option through to the underlying client as a workaround
• Add a swamp doctor / connectivity diagnostic that warns when happy eyeballs is not functioning for a configured baseUrl