fix(fetch): report security details for resumed TLS sessions

[Dmitry Gozman (dgozman)]

Summary

• A resumed TLS session does not carry the server certificate, so getPeerCertificate() returns {} and securityDetails() reported NaNvalidFrom/validTo with no issuer/subjectName.
• Resumption only became possible in chore(net): use native happy eyeballs instead of the manual implementation #42240, which removed the createConnection override that had been bypassing Node's TLS session cache entirely.
• Each APIRequestContext now owns its http/https agent, and certificate details from a full handshake are cached per endpoint. The agent's session cache starts out empty, so the first connection to an endpoint is always a full handshake that populates the cache before any resumption can happen.

Fixes the flaky library/global-fetch.spec.ts:293 and library/har.spec.ts:639. Both have failed on the first attempt in ~100% of CI runs since #42240 landed on Aug 14, and passed on retry, so the runs stayed green.

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/popup.spec.ts:260 › should not throw when click closes popup `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-page] › page/page-emulate-media.spec.ts:144 › should keep reduced motion and color emulation after reload `@firefox-ubuntu-22.04-node20`

51242 passed, 1233 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

4 failed
❌ [chrome] › mcp/config.spec.ts:203 › chromiumSandbox › --sandbox enables the sandbox @mcp-ubuntu-latest-chrome
❌ [chromium] › mcp/http.spec.ts:144 › http transport browser sigint @mcp-windows-latest-chromium
❌ [webkit] › mcp/cli-killall.spec.ts:42 › kill-all kills filtered dashboard pid @mcp-windows-latest-webkit
❌ [webkit] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) @mcp-ubuntu-latest-webkit

8119 passed, 1341 skipped

---

Merge workflow run.

[github-actions]

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

🟢 The PR is clear — all four failures are pre-existing flakes

The MCP report's 4 failures are all known flaky tests with long histories on unrelated SHAs, and none of them exercise the fetch TLS security-details code this PR touches. The "tests 1" report has no real failures (2 flaky only).

Details

This PR only changes packages/playwright-core/src/server/fetch.ts (per-context TLS agent + cached certificate details for resumed sessions) and adds one global-fetch.spec.ts case. The failing tests are all in the MCP suite and don't go through APIRequestContext, so the diff can't reach them.

Pre-existing flake / infra

• [chrome] › mcp/config.spec.ts:203 › chromiumSandbox › --sandbox enables the sandbox — flaky across the results DB: on chrome, final verdict failed 12 of 39 runs, passed 27 (20 more rescued by retry), across SHAs unrelated to this PR.
• [chromium] › mcp/http.spec.ts:144 › http transport browser sigint — flips verdict on multiple browsers on unrelated SHAs (e.g. webkit 3 failed / 730 passed, chromium/firefox 1 failed each, plus within-run retries). Sigint/lifecycle timing flake, not fetch-related.
• [webkit] › mcp/cli-killall.spec.ts:42 › kill-all kills filtered dashboard pid — one of the more bimodal MCP tests: fails on every browser intermittently (webkit 5, chromium 4, chrome/firefox 3 failed finals; 5–10 rescued each) on unrelated SHAs.
• [webkit] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) — same story: webkit 4 failed / 729 passed, plus rescued flakes on chromium/firefox/msedge, on unrelated SHAs.

Each of these fails and passes across many other runs and PRs, which is the flake signature — not something introduced here. The green "tests 1" run confirms the library suite (where this change actually lives, including the new global-fetch.spec.ts case) is passing.

_{Triaged by the Playwright bot - agent run}