fix: track recording process by UDID for targeted stop

[saen-ai]

Summary

stop_recording previously used pkill -f simctl.*recordVideo which killed every recording process on the machine — a problem when multiple simulators are recording simultaneously or when other idb/simctl commands are running concurrently.

This PR fixes that by tracking each recording's ChildProcess in a Map<udid, ChildProcess>. stop_recording now sends SIGINT to that specific PID only.

Fixes #20

Changes

• Added activeRecordings: Map<string, ChildProcess> at module scope
• record_video stores the spawned process after it starts, removes it on exit
• stop_recording accepts an optional udid param, looks up the tracked process, kills by PID
• Falls back to pkill if no tracked process found (e.g. server restarted mid-recording) — never worse than before

Test plan

• Start a recording, then call stop_recording → video file saved correctly
• Start two recordings on two different simulators → stop_recording with one UDID stops only that recording, the other continues
• Restart MCP server mid-recording, call stop_recording → fallback pkill still works

[joshuayoes]

Thanks — PID tracking via a module-level Map<udid, ChildProcess> with an exit handler for cleanup is the right approach, and fixes #20 cleanly. A few things before I can land it:

1. Same stacking issue as feat: add max_size and force params to screenshot tool #63. This branch sits on top of feat: add ui_paste tool for emoji and Unicode text input #60, feat: add terminate_app, open_url, and list_apps tools #61, and feat: add max_size and force params to screenshot tool #63, plus the merged fix: record_video ignores udid, ui_view JSON crash, temp file leaks, dep CVEs #59. Net-real-change for this PR is just commit 611e44e5. Please rebase onto the current joshuayoes/main:

   git fetch upstream
   git checkout -B fix/recording-pid-tracking upstream/main
   git cherry-pick 611e44e5
   git push --force-with-lease origin fix/recording-pid-tracking
   

2. Silent pkill fallback doesn't match the existing error pattern. The current code uses .catch(() => {}) which hides two different outcomes: (a) pkill found nothing to kill (legitimate "no recording in progress" — user should see that message, not a success claim) and (b) pkill failed for an actual reason (should surface via errorWithTroubleshooting like every other tool). Nothing else in this file uses .catch(() => {}) — every tool body just wraps in try/catch and lets errors bubble. Suggest: when the Map lookup misses, either (i) just return "no recording in progress for udid X" without touching pkill, or (ii) run pkill and distinguish its exit codes (1 = nothing matched → friendly message; other nonzero → error through the normal path).

3. Demo recording. Short ## Demo showing two scenarios would help: (a) two concurrent recordings on two UDIDs, stop one, confirm the other keeps going; (b) stop without a tracked process (post server restart) falls back cleanly. See Releases and feat: add ui_find_element tool #51 for format.

4. Non-blocking question. If the MCP server process is killed mid-recording (hard crash, not SIGINT), does the recording subprocess get orphaned and keep writing, or does OS process-tree-termination handle it? Not something to solve in this PR, but worth a test if you haven't already.