Native mobile trace mode costs 40-60s per run in per-action probes

Reported: trace mode "dramatically increases test running time, especially for CI" — 40-60s on iOS — and filmstrip: false does not help.

It cannot help: the cost is not the screencast. In trace mode every mapped action runs getPageSource() and takeScreenshot() (packages/core/src/action-snapshot.ts). They sit in one Promise.all, but a driver serialises per session, so that is two sequential round trips per action. On iOS the WDA page-source XML dump is the expensive half — often a second on its own. ~30 actions x ~1.5s lands on the number he measured.

The per-command screenshot is already skipped on native; this is what remains.

Options worth weighing:

• an option to skip the page-source probe on native (screenshot-only rows)
• full snapshot only for failing actions
• both, with the default chosen for CI rather than for debugging

Prerequisite: something to measure against

There is no example exercising the native mobile capture path, which is why the mobile bugs in this batch were only found by hand-building a harness — and why this issue cannot be closed honestly without one. Any option added here needs a real-device run before and after.

A working harness exists from that investigation: WDIO configs for Android (UiAutomator2) and iOS (XCUITest) driving BrowserStack's own public sample apps, in trace mode with no dashboard, verified end to end on a real Pixel 7 and a real iPhone 17. Landing it needs three decisions:

• where the app under test comes from (the sample apps have to be uploaded, so the app id cannot be hardcoded in a committed config)
• that credentials stay in the environment
• whether it runs in CI at all, or is documented as a manual harness like the other examples