Add explicit Android ADB provider transfer capabilities

[thymikee]

Summary

Follow-up to #481. The Android ADB provider boundary now covers exec, streaming, app/logcat/clipboard/keyboard helpers, and reverse management. The remaining abstraction gap is file transfer and install operations.

Today Android recording/install paths can still rely on ADB-shaped argument calls such as:

• adb pull <remote> <local> for recording artifacts
• adb install <localPath> for app install
• future push/pull-like helper workflows

That works for local ADB and remote providers that intentionally emulate ADB argument semantics against bridge storage, but it is not ideal for pure websocket/cloud providers.

Proposal

Extend the public Android provider contract with explicit transfer/install capabilities, for example:

• pull(remotePath, localPath, options?)
• push(localPath | Buffer | stream, remotePath, options?)
• install(localPath | artifact/input ref, options?)
• clear unsupported-capability errors when a provider cannot transfer files

Then route Android install, recording copy-out, snapshot helper install if applicable, and any future binary/file workflows through those capabilities when available.

Acceptance Criteria

• Android recording copy-out does not require providers to parse exec(['pull', ...]).
• Android app install does not require providers to parse exec(['install', ...]).
• Local ADB provider implements the capabilities by delegating to normal adb commands.
• Exec-shaped fallback behavior is documented if kept for compatibility.
• Conformance tests cover a fake provider with no host adb on PATH and assert file transfer/install activity goes through the provider capability.

Context

Cloud/Limrun can adopt #481's agent-device/android-adb helpers without coupling to daemon internals, but first-class transfer APIs are still needed before all custom Android ADB plumbing can disappear for pure remote providers.