fix: persist XCTest runner port per device — stop orphaning xcodebuild processes

[qwertey6]

Proposed changes

Stop orphaning xcodebuild processes between Maestro runs. Each maestro test invocation was picking a random port from 7001-7128, even when an XCTest runner from a previous run was still listening on a different port. The new run couldn't find a runner on its new port, so it spawned a fresh xcodebuild + runner pair. The old runner got killed by simctl (XCTest only allows one runner per app), but the old xcodebuild process was orphaned and stayed alive forever.

Over many runs, this accumulated orphaned xcodebuild processes that held simulator resources, eventually causing connection failures, timeouts, and the symptoms reported in #1299, #2932, and various flaky-test reports.

Impact

• Saves ~5 seconds per warm run by reusing the existing runner (the isChannelAlive() short-circuit in restartXCTestRunner finally works the way it was meant to)
• No more orphaned xcodebuild zombies filling up the process table
• Cross-platform: file-based store, no lsof/process scanning, works on Windows
• Builds on the runner-reuse work in perf: 4x faster startup — skip unnecessary driver reinstall, cache build products #3139 (which added isChannelAlive() skip but couldn't use it because the port changed every run)

Root cause

TestCommand.selectPort() returns a random port from 7001..7128 for every invocation. The previous run's runner is still listening on its old port (e.g., 7106). The new run picks a new port (e.g., 7117) and:

1. Calls restartXCTestRunner() for port 7117
2. isChannelAlive() checks port 7117 → returns false (old runner is on 7106)
3. Spawns a new xcodebuild test-without-building on port 7117
4. simctl kills the old runner (only one XCTest runner per app at a time)
5. The old xcodebuild is now waiting for its dead runner — orphaned forever

After N runs, there are N orphaned xcodebuild processes. Verified locally by running ps aux | grep xcodebuild after a few maestro test invocations.

Fix

Persist the XCTest runner port per device to ~/.maestro/xctest-ports/<deviceId>. On the next invocation, read the saved port and probe it with isPortListening() (a short-timeout Socket.connect()). If something is listening, reuse the port — the existing isChannelAlive() check in restartXCTestRunner() then short-circuits the entire reinstall path. If nothing is listening, the saved port is stale; pick a new random port and update the file.

Verification

Run	State	Time	Port	Processes
1 (cold)	Fresh start	13s	7106	2 (xcodebuild + runner)
2 (warm)	Reuse	8s	7106 (same)	2 (no orphans)
3 (warm)	Reuse	7s	7106 (same)	2 (no orphans)
4 (after pkill)	Recover	11s	7009 (new)	2 (fresh)

Parallel runs on two simulators each get their own port file and don't interfere.

Why not pick the same port deterministically (e.g., hash deviceId → port)?

Considered. Two issues:

• Hash collisions across devices on the same machine
• The user might have the port in use by something else

The persistent file is more flexible: the port is "sticky" once chosen, but each device picks an actually-available port at first start.

Why not scan running processes to find the port (lsof)?

• Not cross-platform (Windows has no lsof)
• Fragile parsing
• Maestro CLI runs in sandboxes that may restrict process inspection

Cross-platform safety

XCTestPortStore uses java.io.File only — no Unix-specific calls. Works on Windows, Linux, and macOS.

Depends on: #3166 → #3165 → #3141 → #3140 → #3139 → #3138 (stacked PR chain)

Issues fixed

Builds on #3139 to make the driver-reuse optimization actually work across CLI invocations. Likely contributes to fixing #1299 and the broader class of "iOS driver hangs" reports.