fix(net): honor ipv4first dns result order in dual-stack lookup

[Yury Semikhatsky (yury-s)]

Summary

• dualStackLookup always tried IPv6 first and ignored --dns-result-order=ipv4first; it now tries IPv4 first when the process-wide DNS result order is set to ipv4first.
• On networks where IPv6 is set up but not routed, this lets users skip the 5s wait before Node falls back to IPv4. The download timeout itself was fixed in fix(net): apply socketTimeout from socket creation in httpRequest #42660.

Fixes #42799

[github-actions]

Test results for "tests 1"

4 flaky

⚠️ [chromium-library] › library/video.spec.ts:356 › screencast › should work for popups `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`

52270 passed, 1241 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

2 failed
❌ [chromium] › mcp/annotate.spec.ts:110 › should abort annotation when last screenshot is removed @mcp-windows-latest-chromium
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8710 passed, 1480 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a look at the CI failures here.

🟢 Both failures are pre-existing flakes — the PR is clear

mcp/annotate.spec.ts:110 and mcp/cli-core.spec.ts:149 both fail with the same error signatures on main and on unrelated PRs. This PR only changes dualStackLookup in packages/utils/network.ts, which the MCP annotate and file-upload flows don't touch.

Details

The diff is two files: family ordering in dualStackLookup (packages/utils/network.ts) and a new test in tests/library/network-timeout.spec.ts. The new test passed; the tests 1 run was fully green apart from four unrelated flakes. The only red is the MCP shard, and neither failing test resolves a hostname through dualStackLookup.

Pre-existing flake / infra

• [chromium] › mcp/annotate.spec.ts:110 › should abort annotation when last screenshot is removed (mcp-windows-latest-chromium) — fails with Cannot read properties of undefined (reading 'endpoint') followed by a 180s test timeout. The same test fails with the identical error on shas this PR can't touch: 0c0594d4 and 9642f576 (both push runs, no PR), and PR chore: introduce _TestInfoEx interface for builtin fixtures #42352 at a2867b12. Across the results DB it flips verdict on five different MCP bots — e.g. 2 failed / 311 passed on mcp-windows-latest-chrome, 1 / 722 on mcp-windows-latest-msedge.

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files (mcp-windows-latest-firefox) — fails on expect(...).toContain('await fileChooser.setFiles(') with The tool "browser_file_upload"... instead. Same test, same error, on push shas f1d33b50 and 52a0e720, and on PRs fix(mcp): follow symlinks when checking file access against workspace roots #42628, chore(trace): remove snapshot pointers from action events #42431 and feat(video): allow configuring screencast bitrate #42407. On this bot it's 5 failed / 379 passed; it also flakes on the macOS and Ubuntu Firefox bots (2 retry-rescued runs each).

_{Triaged by the Playwright bot - agent run}