fix(recorder): support re-enabling recorder on the same context

[Yury Semikhatsky (yury-s)]

Summary

• RecorderApp.show is renamed to enable and now supports repeated enableRecorder calls on the same context: at most one recorder app (inspector window or programmatic) is active per context, and params.mode is applied explicitly since Recorder.forContext ignores params of an existing recorder — enable after disable used to silently record nothing.
• ProgrammaticRecorderApp unsubscribes its recorder listeners on close, disableRecorder now closes the active app of either kind, so recording can be re-enabled in a different mode.

Extracted from #42359.

[github-actions]

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

🟢 CI is clear — the one failure is a pre-existing flake

mcp/http.spec.ts:144 › http transport browser sigint failed on mcp-windows-latest-firefox, but it's a known Windows-only flake unrelated to this PR. This PR only touches recorder code, which the MCP HTTP sigint path doesn't exercise.

Details

This PR changes recorderApp.ts (the recorder app dedup guard / setMode) and a recorder test. Nothing here touches the MCP server, its HTTP transport, or browser SIGINT shutdown.

Pre-existing flake / infra

• [firefox] › mcp/http.spec.ts:144 › http transport browser sigint (mcp-windows-latest-firefox) — pre-existing flake, Windows-only across all three engines. In the CI results DB it failed 9 of 9132 runs (~0.1%), exclusively on mcp-windows-latest-* bots — chromium, firefox, and webkit — on unrelated SHAs and PRs (fix(fetch): report security details for resumed TLS sessions #42331, fix(dashboard): don't strand a stale tab selection on session switch #42290, test(mcp): fix flaky 'click link' on firefox #42275, feat(test-runner): annotate serial suites for custom sharding #42164, feat(trace): split API requests into a separate network stream #42073) as well as push runs. On this bot specifically it's green in 650 of 652 runs; this PR's run is one of the two reds:

  🟩🟩🟩🟩🟩🟩🟥

  The signature (process SIGINT shutdown racing on Windows) and the fact that it flakes identically on engines this PR can't affect both point away from the diff.

The 7 "flaky" entries in the tests 1 report all passed on retry and don't touch recorder code — nothing to triage there.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "tests 1"

5 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/popup.spec.ts:260 › should not throw when click closes popup `@chromium-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsertype-connect.spec.ts:807 › launchServer › should upload a folder `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/heap.spec.ts:223 › should not leak workers `@firefox-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:715 › should indicate current test status `@windows-latest-node22`

51385 passed, 1238 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

8142 passed, 1361 skipped

---

Merge workflow run.