test(mcp): fixme flaky annotate screencast test on Firefox/Windows

[microsoft-playwright-automation]

The MCP CLI test "should switch screencast to -s session on show --annotate"
flakes only on the mcp-windows-latest-firefox bot. connectToDashboard polls
cli list --all --json for the bound show server, but on Firefox/Windows the
server occasionally never registers within the 90s budget, so the poll exhausts
and the run dies with "Cannot read properties of undefined (reading 'endpoint')"
at tests/mcp/cli-fixtures.ts (server.endpoint). Scope a fixme to that config;
it keeps running everywhere else.

DB evidence (rolling CI window, 354 runs on mcp-windows-latest-firefox):
18 failed runs, fails exclusively on this bot, low steady rate through
2026-08-03; passes on every other browser and OS. No linked issue or open PR.

Run history (mcp-windows-latest-firefox, oldest first, 354 squares):

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟥🟥🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟥🟩🟥🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟩

Verified locally on windows-latest:

• npm run test-mcp -- --project=firefox tests/mcp/annotate.spec.ts:446 -> 1 skipped
• npm run test-mcp -- --project=chromium tests/mcp/annotate.spec.ts:446 -> 1 passed (still runs elsewhere)
• npm run flint -> clean (pre-existing unrelated check-deps path warning only)

Run: https://github.com/microsoft/playwright/actions/runs/30886770686

Suggested-reviewer: Skn0tt

[github-actions]

Test results for "MCP"

7971 passed, 1285 skipped

---

Merge workflow run.

[Skn0tt]

@copilot can you please look at the test results DB to figure out if this flakiness was introduced by a particular commit? The diagram looks like it.

[Copilot]

@copilot can you please look at the test results DB to figure out if this flakiness was introduced by a particular commit? The diagram looks like it.

I dug into the run history (I can't query the results DB directly from the agent sandbox, so this is based on the runs listed in the description plus the Actions API).

The boundary isn't clean, unfortunately:

• Last 172 runs before 2026-07-23 are all green.
• First red is run 30014511758 (2026-07-23 14:09, PR branch recorder-unify-coalescing, based on main at 1299d0f6c).
• The immediately preceding main run 30013096074 is main at the same 1299d0f6c, 18 minutes earlier, and this test passed there.

So last-green and first-red share the same base commit — there's no commit that flipped it deterministically, which fits the low steady failure rate afterwards (18/354, no clustering on any one PR or branch).

The suspects that landed in the two-day window right before the first red, all touching what this test exercises:

• 244a1ffd feat(firefox): roll to r1538 (feat(firefox): roll to r1538 #41938), 07-22 — only bot affected is Firefox/Windows, so a browser roll is the best fit for "started flaking, one browser only".
• ea219e66 fix(dashboard): avoid stdout readiness race (fix(dashboard): avoid stdout readiness race #41901), 07-21 — removes the explicit stdout flush before cli show returns; the failure mode is exactly "the bound show server never shows up in cli list --all --json". But runs on 07-21/07-22 already contained it and were green, so it's second on my list.
• bc97a130 fix(screencast): acknowledge frames after callbacks (fix(screencast): acknowledge frames after callbacks #41898), 07-21.

If you want a firmer answer, a rerun of the mcp-windows-firefox job at 244a1ffd~1 vs 244a1ffd a few times would settle the Firefox-roll hypothesis — I can't trigger that from here.