[BUG] Agent teams: teammate sessions die with ConnectionRefused (Bun tries IPv6, no IPv4 fallback) while the lead keeps working

Summary
With agent teams enabled (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), spawned teammate sessions fail with Unable to connect to API (ConnectionRefused) while the lead session keeps working. Root cause is not agent-teams specific: the underlying Bun HTTP client attempts the AAAA (IPv6) address and does not fall back to IPv4 (RFC 8305 Happy Eyeballs) when IPv6 is present but unroutable. curl, Node fetch, and browsers work on the same machine because they fall back to IPv4.

Agent teams symptom (how it first showed up)
The lead session keeps working while spawned teammates die with ConnectionRefused. Each teammate is an independent session opening its own connection; whichever attempts the AAAA address fails, while the lead (already on a live IPv4 connection) is unaffected. This looks like an agent-teams bug but is the IPv6/no-fallback issue below. The same error also appears as OAuth error: ECONNREFUSED during /login.

Environment

• Claude Code 2.1.179
• macOS 15.6.1, Apple Silicon
• A VPN (Tailscale) was active, which adds a global IPv6 address + IPv6 default routes that black-hole public IPv6. Any setup with broken/partial IPv6 should reproduce.

Evidence

• api.anthropic.com → A 160.79.104.10, AAAA 2607:6bc0::10
• Direct IPv6 connect fails instantly: connect EHOSTUNREACH 2607:6bc0::10:443 (~2ms)
• curl https://api.anthropic.com → HTTP 405 (works — falls back to IPv4)
• Node fetch("https://api.anthropic.com/...") → HTTP 401 (works — falls back to IPv4)
• Claude Code → ConnectionRefused, retries 1/10…10/10, never recovers
• tcpdump during a failing launch shows the client attempting the AAAA address; after forcing IPv4, capture shows thousands of IPv4 packets / 0 IPv6 and it connects fine.

Notably: taking the VPN down fixes Node (the OS getaddrinfo then returns IPv4-only via AI_ADDRCONFIG) but does not fix Claude Code — indicating the Bun runtime resolves the AAAA directly rather than via the OS resolver, so it keeps trying IPv6.

Workaround
Pin Anthropic hosts to IPv4 in /etc/hosts (api.anthropic.com, console.anthropic.com, claude.ai, platform.claude.com → 160.79.104.10), then flush DNS. Teammates, connection, and login all work afterward.

Request
Implement Happy Eyeballs / IPv4 fallback in the runtime's connection logic, or expose a documented force-IPv4 flag/env var. This would resolve a recurring class of ConnectionRefused reports. Related: #56242, #17541, #33355, #20288.