fix(cli): do not lose live sessions to transient pipe connect failures

[yury-s]

Summary

• Windows named-pipe servers pre-post only 4 accept instances (libuv default), so a burst of concurrent clients (registry probes, dashboard trackers, playwright-cli list) can transiently fail to connect. serverRegistry.list() treated any failed probe as a dead session and deleted its registry entry, permanently hiding a live session from the dashboard — show --annotate -s=<session> then engaged against the previously selected session.
• Set NODE_PENDING_PIPE_INSTANCES=32 for our pipe servers, prune registry entries only on ECONNREFUSED/ENOENT, and cap probes with a timeout instead of hanging on a busy pipe.
• Fixes the flaky should switch screencast to -s session on show --annotate (and the #display visibility variant) on windows-firefox bots.

Recent failures of the test on windows-firefox:

• https://github.com/microsoft/playwright/actions/runs/30948261262/job/92123562988 (active session stuck)
• https://github.com/microsoft/playwright/actions/runs/30935167147 (active session stuck)
• https://github.com/microsoft/playwright/actions/runs/30933859906 (#display never visible)
• https://github.com/microsoft/playwright/actions/runs/30864655498 (active session stuck)
• https://github.com/microsoft/playwright/actions/runs/30854798207 (active session stuck)
• https://github.com/microsoft/playwright/actions/runs/30852617825 (#display never visible)
• https://github.com/microsoft/playwright/actions/runs/30850842677 (active session stuck)

[Skn0tt]

It's still failing on windows-firefox, so this doesn't seem ready yet.

[github-actions]

Test results for "MCP"

5 failed
❌ [chrome] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed @mcp-windows-latest-chrome
❌ [chromium] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed @mcp-windows-latest-chromium
❌ [firefox] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed @mcp-windows-latest-firefox
❌ [msedge] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed @mcp-windows-latest-msedge
❌ [webkit] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed @mcp-windows-latest-webkit

8045 passed, 1284 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

5 flaky

⚠️ [chromium-library] › library/video.spec.ts:495 › screencast › should capture static page in persistent context @smoke `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/chromium/oopif.spec.ts:282 › should click `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/video.spec.ts:495 › screencast › should capture static page in persistent context @smoke `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`

51232 passed, 1190 skipped

---

Merge workflow run.

[github-actions]

🔴 One failure looks caused by this PR

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

mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed fails on all five Windows browsers at once, and it lives right in the concurrent pipe-connect path this PR retunes. Across the whole test-results DB it has never failed outside this branch — every red row is PR #42128. That's a regression, not a flake.

Details

The latest MCP report (run 31036678317) has five failures, all the same test on mcp-windows-latest-{chrome,chromium,firefox,msedge,webkit}. The "tests 1" report had only flaky / passed-on-retry tests — nothing to triage there.

Caused by this PR

• [chrome|chromium|firefox|msedge|webkit] › mcp/dashboard.spec.ts:184 › two concurrent cli show invocations both succeed on mcp-windows-latest-*. The test fires two concurrent cli show invocations and asserts they converge on one dashboard (expect(first.dashboardPid).toBe(second.dashboardPid)). The diff sets NODE_PENDING_PIPE_INSTANCES=32 in decorateServer for Windows pipe servers and reworks the registry probing — exactly the concurrent named-pipe connect behaviour this test exercises, and the change is gated to process.platform === 'win32', which matches the Windows-only, all-browsers failure pattern. History backs the regression call: ~400+ runs per Windows browser and ~650 per ubuntu/macos bot, 0 failures except this PR (branch fix-dashboard-session-probe, shas 7be71e93 and 1815f4f5). Deterministic across every Windows browser plus PR-only history point at the change, not noise — worth a look before merge.

Pre-existing flake (this PR's own target)

• [firefox] › mcp/annotate.spec.ts:446 › should switch screencast to -s session on show --annotate — not in this latest report (it passed here), but it showed up in earlier runs on mcp-windows-latest-firefox and is the flake this PR sets out to fix. The DB confirms it's pre-existing and unrelated to the diff's subject: 23 failures over ~400 runs across 19 different PRs on windows-firefox alone, plus flaking on macos/ubuntu bots. Not a new regression.

_{Triaged by the Playwright bot - agent run}

[yury-s]

The Windows CI failures (Dashboard daemon exited (code=3221225477), dashboard.spec.ts "two concurrent cli show invocations") were caused by the NODE_PENDING_PIPE_INSTANCES env var: setting it makes any process that loses a named-pipe bind race crash with 0xC0000005 on Node 22/24/26 (the dashboard singleton acquisition deliberately races binds). Reported upstream with a standalone repro:

• Node.js issue: NODE_PENDING_PIPE_INSTANCES causes 0xC0000005 crash on Windows when a named-pipe listen() loses a bind race (EADDRINUSE) nodejs/node#65057
• libuv fix: win: fix crash when closing a pipe after a failed bind libuv/libuv#5224

The env var change is reverted in this PR until the upstream fix lands.