fix(network): suppress external AAAA when host IPv6 egress is unavailable

[mdsalnikov]

Summary

Fixes #607

This PR prevents guests from receiving external AAAA DNS answers when the host cannot route external IPv6 traffic. In that case, the DNS forwarder now returns a successful NODATA response for external AAAA queries, allowing clients such as httpx.AsyncClient to fall back to IPv4.

The internal host.microsandbox.internal AAAA response is preserved.

Motivation

Async HTTP clients may attempt IPv6 connections when the guest receives AAAA records. On hosts without usable external IPv6 routing, those connections fail before the client reaches the working IPv4 path, causing errors such as:

httpx.RemoteProtocolError: Server disconnected without sending a response

Synchronous clients often avoid the issue by using IPv4 first, which is why the failure was client-dependent.

Changes

• Probe host IPv6 egress once when building the DNS forwarder.
• Suppress external AAAA responses with DNS NoError and no answers when IPv6 egress is unavailable.
• Keep A records and host.microsandbox.internal AAAA behavior unchanged.
• Add unit tests for:
  • NODATA response shape.
  • AAAA suppression decision logic.
  • IPv4 queries remaining unaffected.
  • Host alias AAAA remaining available.

Test Plan

• cargo fmt --all --check
• cargo build -p microsandbox-cli
• cargo test --workspace
• cargo clippy --workspace -- -D warnings
• cargo doc --workspace --no-deps
• pre-commit run --all-files
  • Passed all hooks except no-commit-to-branch, because the local branch was protected.
• Manual local repro with signed msb:
  • requests client succeeds.
  • httpx.AsyncClient client succeeds.

---

^{Need help on this PR? Tag @codesmith with what you need.}

• Let Codesmith autofix CI failures and bot reviews

[toksdotdev]

hmm. opening a TCP connection here increases latency significantly. plus, it makes us dependent on cloudflare, which isn't something we want.

i really do think there's more to the bug than is. for sanity, can you try running the following on your host:

curl -6 -m 5 -s -o /dev/null -w '%{http_code}\n' https://[2606:4700:4700::1111]/

trying to distill if this is some issue in our DNS interception layer, or somewhere else? if you're free, can you shoot me a message on discord so we can troubleshoot?

[mdsalnikov]

curl -6 -m 5 -s -o /dev/null -w '%{http_code}\n' https://[2606:4700:4700::1111]/
000

[mdsalnikov]

Replaced to 0x2001, 0x0db8, 0, 0, 0, 0, 0, 1 that is reserved specifically for documentation examples
And in this version it should be faster