record stop fails with INVALID_ARGS "no active recording" while its on-device screenrecord process is still running

[thebillzh]

Summary

record start succeeds and spawns screenrecord on the device (confirmed via adb shell ps).
A later record stop — sometimes only ~2 minutes later, well inside the 180s Android cap —
fails with:

{"code":"INVALID_ARGS","message":"no active recording"}

The daemon has lost its recording-session state, so stop never signals the process or pulls
the file. The recording keeps running until Android's 180s screenrecord cap, and the MP4 is
stranded on the device at /sdcard/agent-device-recording-<epoch>.mp4.

Evidence

• In the daemon's own request logs (<state-dir>/sessions/<session>/requests/*.ndjson),
  7 of 10 historical record stop calls failed with this exact error, each responding within
  ~2s of the request — i.e. the tracked state was already gone at stop time. This is not a
  race with the 180s cap: several failures occurred with the on-device process still alive
  and mid-recording.
• We accumulated 10 orphaned /sdcard/agent-device-recording-*.mp4 files (3–19 MB each)
  over roughly a month of use — one per unrecovered failure.
• Manual recovery works every time, which suggests only the daemon-side bookkeeping is
  broken: send SIGINT to the on-device screenrecord pid (so the moov atom finalizes),
  wait for exit, then adb pull the newest matching file. The pulled files are valid,
  playable MP4s.

Environment

• agent-device v0.18.3 (latest on npm at time of filing), installed globally
• macOS 15 host
• Physical Android device (Android 16 / SDK 36) connected over USB
• Daemons isolated per project via --state-dir (we adopted per-project state dirs
  specifically to avoid concurrent sessions killing each other's daemons; this failure
  still occurs with isolation in place)

Secondary: auto-chunking claim in --help never observed

The CLI help states recordings longer than 180s come back as multiple MP4 chunks. Across all
our logs we have never observed a second chunk being produced — long recordings simply stop
at the cap (and when stop also hits the bug above, the single capped file is stranded).
Either the chunking is broken or the help text should be corrected.

Suggested fix

Make record stop self-heal: when tracked session state is missing but a live screenrecord
process matches the daemon's own output-path convention, SIGINT it, wait for exit, pull and
validate the file — instead of returning INVALID_ARGS. Happy to provide sanitized request-log
excerpts or run a debug build if useful.