feat: recorder open modes (new tab/window/incognito) + close-on-stop

[su-usman]

Closes issue: n/a (BrowserStack LTS-4294 — internal)

📜 Summary of changes:

Adds config-driven "Open recording in" modes to the network recorder, driven by Load Testing (LTS) via the startNetworkRecording config. All fields are optional/additive, so existing callers are unaffected.

• openMode: "tab" (existing default) | "window" | "incognito". Window/incognito open via chrome.windows.create, preserving the about:blank → register body-recorder → navigate sequence and the synchronous sidePanel.open() user gesture.
• closeOnStop: on a user-initiated stop, close the recording tab (tab mode) or window (window/incognito), then refocus the originating LTS context. Focus is applied after the removal resolves so it wins Chrome's post-close focus shuffle (matters when multiple profiles are open).
• Incognito gating: chrome.extension.isAllowedIncognitoAccess() (seeded at SW init, re-seeded on every getExtensionMetadata) is surfaced as incognitoAllowed. Start rejects with a typed code (INCOGNITO_NOT_ALLOWED / INCOGNITO_DISABLED_BY_POLICY) instead of silently downgrading to a normal window.
• Metadata: getExtensionMetadata now returns incognitoAllowed + a supportsOpenModes capability flag (consumers gate on capability, not a version check); startNetworkRecording echoes the resolved openedMode.
• Manifests: explicit "incognito": "spanning" (chrome/edge/firefox) — never split (which would fork the SW and break the external port).
• Robustness: defensive frameId guard on the SDK body-capture path (keeps requestScope: "top-level" honest if allFrames is ever added); re-assert body-recorder registration on windows.onCreated (works around Chromium 1393762, where dynamically-registered content scripts stop injecting into incognito after an extension toggle).

🎥 Demo Video:

Recorded booking.com in a New incognito window — the side panel opens inside the incognito window, capture streams to LTS (235 requests / 57 XHR), and LTS auto-correlation extracts tokens from the captured response bodies. (Screenshots / Loom to attach.)

✅ Checklist:

• Linting + build pass; no new install/build warnings.
• Verified UI in Chrome — New tab, New window, and New incognito window (panel opens, capture + auto-correlation confirmed).
• Firefox manual test (pending — incognito is a separate per-addon opt-in there).
• Unit tests: no SW unit suite in this area; covered by mv3/test/network-recording-test.html + Playwright e2e.

🧪 Test instructions:

1. Load the MV3 build; from an LTS recorder, start a recording with config.openMode = window or incognito (incognito requires "Allow in Incognito" enabled for the extension at chrome://extensions).
2. Confirm the recording surface opens, the side panel appears, and entries stream to LTS.
3. Hit Stop — confirm the tab (tab mode) or window (window/incognito) closes and focus returns to the LTS tab.
4. Incognito without "Allow in Incognito": confirm start returns INCOGNITO_NOT_ALLOWED (no silent downgrade to a normal window).

🔗 Other references:

BrowserStack LTS-4294. Contract mirrored in the LTS-side handoff doc (RECORDER_OPEN_MODES_AND_SCOPE_HANDOFF.md).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[nafees87n]

Looks good. Just one minor caveat

[nafees87n]

Why do we need to hardcode the compatibility flag here? Can't the consumer check this based on version