Document mobile capture in the README and on the devtools site

The README's 📱 Mobile testing section describes one behaviour — snapshot elements come from the XML tree, context-options records the device — and that is now a small fraction of what the adapters do on a mobile session. A reader cannot tell from it that native apps are supported at all, that a hybrid app is followed into its webview, that the dashboard frames a phone as a device, or what a mobile trace does and does not contain.

CONTRIBUTING requires a user-facing change to update the README and mirror to website/docs/devtools in the webdriverio/webdriverio repo. The site currently has nothing about mobile, so there is no path to this capability except reading the repo.

What the section needs to explain

Written as current behaviour a newcomer can act on, not as a history of changes:

• Session kinds. Three cases behave differently and the difference is the whole story: a mobile browser session, a native app session, and a hybrid app that moves between the two. Whether a session has a document is what decides the capture path, and for a hybrid app that answer changes mid-run with the active context — capabilities alone cannot answer it.
• What each adapter does. All four adapters detect a native session and skip page-side capture on one; a reader should be able to tell what to expect from whichever one they use.
• What the dashboard shows. A phone capture is framed as the device, with the action list and dock beside it, in both live and trace mode.
• What a mobile trace contains, and what it does not. On a hybrid app's webview actions there is no per-action element data, accessibility tree or settle screenshot. This is the single most important thing to state plainly: someone debugging a mobile trace needs to know which absences are by design so they don't read them as a bug.
• Native vs mobile-web expectations. Element data comes from the platform's XML tree rather than the DOM, so locators and the A11y panel look different from a browser run.

Prerequisites

The prereq list needs a pass for accuracy rather than a rewrite. The Chromedriver step pins against a Chrome version several years old; the failure it guards against still happens, and presents as No Chromedriver found that can automate Chrome '<version>' when entering a webview — worth naming, because it reads as a devtools fault and is not one. The ANDROID_HOME note is correct and should stay.

Acceptance criteria

1. README's mobile section explains the three session kinds, per-adapter behaviour, what the dashboard renders, and the trace's documented gaps.
2. Same content on website/docs/devtools, linked from the per-framework pages, so mobile is reachable without the repo.
3. Prereqs corrected, with the webview Chromedriver failure named as an environment gap.

Constraint

Document only what is committed. The mobile examples, the native and hybrid specs and their configs are deliberately local-only (.git/info/exclude); linking them from the README or the site points a reader at files that are not in the repo. examples/wdio/cucumber/wdio.mobile.conf.ts is tracked and may stay linked.

Size: M.