Android: one persistent automation helper owning snapshot + viewport + canonical injection #1275

Context

Android gesture execution currently stops the persistent snapshot instrumentation before injecting (src/platforms/android/multitouch-helper.ts — gesture execution tears down the snapshot helper; the next capture restarts it). During PR #1217 validation this instrumentation churn was measured as a dominant cost around Maestro swipe steps, and it taxes every local Android gesture, not just Maestro.

Direction (agreed during #1217 review)

One persistent Android automation helper owning:

• snapshot capture;
• gesture viewport resolution;
• canonical one- and two-pointer plan injection (ADR 0013 boundary unchanged).

It atomically replaces the separate one-shot multitouch helper — no "active session" optimization with a legacy fallback, and no second production path. Touch scheduling/injection should be extracted into focused Java classes rather than growing the existing ~770-line snapshot instrumentation.

Prototype gate (measure before committing)

1. persistent-helper touch request latency;
2. touch → two stable snapshots without process restart;
3. five consecutive scrollable-pager passes;
4. a long one-pointer pan;
5. pinch, rotate, transform, and two-finger pan canaries (plans and app-observable effects unchanged).

Related

• perf(android): reuse touch-helper preparation across scroll viewport and injection #1250 (reuse touch-helper preparation across scroll viewport and injection) — subsumed by this if it lands.
• Harden Android snapshot helper so stock UIAutomator fallback can be removed #1253 (harden snapshot helper to drop stock UIAutomator fallback) — same helper family; coordinate so the consolidation doesn't reintroduce a fallback.
• Ship a minimal test IME as an Android helper APK for deterministic text entry and clean settle diffs #1198 (test IME as helper APK) — sibling helper-APK packaging pattern.