test(mobile): add standalone E2E coverage + document the standalone Appium contract (RN + Flutter)

Summary

The standalone session helpers for the mobile services already ship and are unit-tested, but — unlike every desktop service — they have zero E2E coverage, and the standalone contract (which differs from the testrunner path in two material ways) is undocumented.

This is the mobile half of the standalone/multiremote coverage audit. (Multiremote is tracked separately.)

What already exists

• packages/native-mobile-core/src/session.ts — createMobileSession() factory: drives launcher.onPrepare() → remote() → manually calls worker.before() → tracks launcher/worker for cleanup(). Same shape as the desktop init() in electron/tauri/dioxus src/session.ts.
• packages/react-native-service/src/session.ts + packages/flutter-service/src/session.ts bind it to their launcher/worker and export startWdioSession / cleanupWdioSession / createReactNativeCapabilities|createFlutterCapabilities (react-native-service/src/index.ts, flutter-service/src/index.ts) — identical public surface to Tauri/Dioxus.
• Unit-tested: native-mobile-core/test/session.spec.ts, react-native-service/test/index.spec.ts, flutter-service/test/index.spec.ts.
• The worker before() is self-sufficient given a live Appium session — RN's MetroBridge discovers/connects to Hermes itself; it does not depend on launcher-stamped state. So standalone works functionally.

The gaps

1. No E2E coverage. No e2e/test/react-native/standalone/ or e2e/test/flutter/standalone/ specs, no test:e2e:*:standalone script, no CI leg — the mobile reusable workflows (_ci-e2e-react-native.reusable.yml, _ci-e2e-flutter.reusable.yml) run standard only. Desktop runs standalone in its CI matrix. The shipped startWdioSession export is never exercised against a real device.

2. Two undocumented divergences from the testrunner path:

• Appium isn't auto-spawned. The runner path composes @wdio/appium-service (e2e/wdio.react-native.conf.ts services:); standalone init() does not — it assumes an externally-running Appium and defaults to localhost:4723/ (overridable via the connection arg). A caller expecting remote()-style self-contained startup gets a connection failure.
• No device claiming / appium:udid stamping. Standalone drives only launcher.onPrepare(), never onWorkerStart() — and onWorkerStart is where DeviceManager.claim() + applyToCapability() stamp the udid (native-mobile-core/src/launcher.ts). Standalone therefore relies on Appium's default single-device selection (or a caller-supplied udid). Fine for one device; a real divergence from the pooled runner behaviour, and nowhere documented.

Proposed work

1. E2E specs for RN + Flutter mirroring e2e/test/tauri/standalone/api.spec.ts (session create → a representative execute/mock assertion → cleanupWdioSession). Cost is low — single device (same as standard), and CI already runs Appium. Cheapest wiring: append to the existing standard job to reuse the already-booted emulator + running Appium, rather than a second matrix leg that re-boots an emulator.
2. Docs: the standalone Appium-server contract (external Appium, localhost:4723 default, connection override) and the single-device/udid caveat (no pool claiming in standalone).

Out of scope

• Multiremote E2E (separate issue).
• Spawning Appium from the standalone helper — current "bring your own Appium" contract is fine; this issue only asks that it be documented.

Start with e2e/test/tauri/standalone/api.spec.ts and the mobile session exports, then inspect _ci-e2e-react-native.reusable.yml and _ci-e2e-flutter.reusable.yml. Add RN and Flutter standalone specs covering session creation, a representative execute/mock assertion, and cleanup, and document the external Appium and single-device contract. Done means both specs run in the existing standard CI jobs.