Route Android daemon ADB operations through a provider executor

[thymikee]

Context

PR #474 adds Android frame-health sampling to perf using adb shell dumpsys gfxinfo <package> framestats. This works for local daemons and for remote providers that expose the leased Android device through a daemon-side adb CLI/shim.

For lim.run-style remote ADB-over-websocket providers, this is not guaranteed if the daemon only has a JS/websocket ADB API and no local adb command target.

Problem

Several Android daemon paths still shell out directly through runCmd('adb', ...), including:

• perf frame health, CPU, and memory sampling
• Android log recovery/runtime hints in some paths
• other Android command helpers that use adbArgs(device, ...)

The Android snapshot helper already supports a provider-injected ADB-shaped executor, but that abstraction is not shared by daemon command paths.

Desired direction

Introduce a shared Android ADB executor layer for daemon/platform operations so local and remote providers can route the same command arguments through either:

• local adb -s <serial> ...
• a daemon-side adb shim
• a websocket/tunnel-backed provider executor

The executor should preserve normalized errors, timeouts, stdout/stderr/exit code semantics, and diagnostics enough for existing command handlers.

Acceptance criteria

• Android perf uses the shared executor instead of directly calling runCmd('adb', ...).
• Provider-backed remote daemons can inject an ADB executor without changing the public perf command contract.
• Local behavior remains unchanged.
• Remote/websocket unavailable cases fail with clear, per-metric unavailable reasons instead of requiring local ADB.
• Tests cover local executor behavior and an injected executor path for at least perf.

Notes

This would make Android frame health on lim.run reliable even when the device is reachable only through a remote ADB websocket, and would likely benefit logs/runtime-hints follow-ups too.