Harden Android recording recovery across daemon restarts

[thymikee]

Context

Follow-up from #1117 and PR #1129.

PR #1129 stops the immediate failure mode: when daemon memory is lost while Android screenrecord is still running, record stop can recover the active device-side recording instead of returning no active recording and leaving an orphaned MP4.

That fix intentionally stays narrow. The next step is to make Android recording recovery durable across daemon restarts, chunk rotation, and session ownership boundaries.

Blocked by: #1129 for merge to main. If this starts before #1129 merges, stack on fix/android-recording-recovery-1117 or explicitly rebase once #1129 lands.

Problem

Android recording state is still mostly daemon-memory state:

• the active screenrecord pid/path can be recovered, but the recording owner/session is not durably encoded enough for exact matching after daemon restart
• chunk rotation state and prior remote chunks can be lost when the daemon dies
• Android long-recording help/docs imply chunking, but chunking depends on the daemon rotation loop staying alive
• recovery has live emulator evidence for the marker path, but automated coverage currently focuses on process-scan fallback
• some Android process/discovery probes can hang unless every path has explicit bounded timeouts

Scope

Implement this as one coherent Android recording recovery hardening pass:

1. Persist a durable Android recording manifest while recording is active.

   • include session name, recording id or equivalent owner token, startedAt, current pid/path, chunk list, output/telemetry intent where appropriate, and enough metadata to validate recovery safely
   • keep the manifest updated when chunk rotation starts a new screenrecord
   • clean the manifest on successful stop and stale/invalid recovery cleanup

2. Make record stop --session <name> recover only matching durable state.

   • do not stop another session’s recording after daemon restart
   • return an actionable error when durable state exists but belongs to another session or is ambiguous
   • keep stale markers/manifests best-effort cleaned up

3. Rehydrate chunk-aware stop behavior where feasible.

   • if prior chunks are known in the manifest, pull and finalize all recoverable chunks
   • if data is unrecoverable, return a bounded warning that explains what was preserved and what could not be recovered
   • avoid claiming full long-recording chunking guarantees after daemon loss unless the manifest actually preserves them

4. Add automated coverage.

   • provider-backed marker/manifest recovery path
   • stale manifest cleanup
   • wrong-session/ambiguous recovery refusal
   • chunk-list recovery or explicit warning behavior
   • timeout behavior for process/discovery fallback

5. Audit Android recording/process probes used by this flow for bounded timeouts.

   • do not add unbounded adb shell ps or similar probes
   • prefer structured/bounded probes where possible

6. Update command help/docs if user-visible recording semantics change.

   • especially Android 180s chunking and what is guaranteed after daemon restart

Acceptance Criteria

• After daemon restart, Android record stop --session <same-session> can recover the correct active recording from durable state.
• record stop --session <different-session> does not stop or pull another session’s recording.
• Recovered recordings either include all manifest-known chunks or return a clear warning describing the lost/unavailable part.
• Stale or invalid manifests are ignored safely and cleaned up best-effort.
• Android recovery probes have explicit timeouts.
• Provider tests cover the durable recovery path and safety refusals.
• Live emulator/device verification is performed for the primary restart recovery path. If chunk recovery cannot be verified live without an impractical 180s run, explain the substitute evidence.

Suggested Validation

• pnpm format
• pnpm typecheck
• pnpm build
• focused record-trace unit/provider tests
• pnpm test:integration:provider
• emulator verification on Android: start recording, interact with the app, stop daemon mid-recording, run record stop from a fresh daemon, confirm the MP4 is pulled and no screenrecord process remains