[Bug]: macOS 15.2+: in-app MCP startRecording opens Apple's picker instead of recording the window, then times out #1232

Platform: macOS 26.5 (M1), CI build of main @ 61fa43812 (run 38615516865, notarized). Found in the retest logged in #1231.

Repro

1. Launch OpenScreen normally, without OPENSCREEN_MAC_SOURCE_PICKER, on macOS 15.2 or later, with Screen Recording granted.
2. In AI settings, turn on the MCP server and MCP edits.
3. From an MCP client: startRecording with window: "<a window from listSources>", systemAudio: true.

Expected: the editor closes and the recording bar records that window, as the in-app tool description and the checklist say, and as the stdio server does.

Actual: the editor closes and Apple's "Share a Window or Entire Screen" picker opens, waiting for a click. With nobody at the Mac, the call fails after 120 s with "capture had not started". The picker then stays on screen after the timeout, and even after OpenScreen quits, until someone presses Cancel.

Cause: pointHudAtTake in electron/ipc/handlers.ts clears the selected source on purpose when macPickerOwnsSources(): "Apple's picker asks for this take". The window and display arguments are never used on macOS 15.2+. With OPENSCREEN_MAC_SOURCE_PICKER=legacy the same call starts in 4.3 s and records the window.

Impact: on a default install of a supported macOS, the in-app server cannot record unattended, which is what an agent calls it for. It also leaves a system picker stuck on the user's screen.

Direction: for an MCP take that names a window or a display, pick that source the way the legacy path and the stdio server do. That path needs the Screen Recording grant; when the grant is missing, refuse with a message that says so instead of falling back to the picker. Separately, a take that times out should end its picker session, so the picker does not outlive the request.