Fix persistent GPS watchdog false clears

[Lemelson]

What changed

• replace the blocking Process.waitUntilExit() timeout race with a termination-handler based command runner that returns promptly and kills timed-out children
• move monitoring ownership from a SwiftUI view task to the app controller and refresh status on app activation
• add a kernel-held GUI liveness lease so a delayed, App-Napped, or suspended UI cannot be mistaken for a crash
• make the worker require both a stale heartbeat and proof that the GUI process is gone before restoring real GPS
• decode the Application Support path before passing it to POSIX open() and retry lease acquisition on an explicit Start
• bump the app to 1.5.1 (8) and document the corrected safety behavior

Root cause

A timed-out launchctl check stranded a synchronous waitUntilExit() child inside a structured task group. The controller's only polling task never resumed, so both the heartbeat and UI status froze. Exactly five minutes later the worker treated the stale heartbeat as an app crash, sent clear, and stopped, while the stale UI still showed Belgrade as active.

User impact

When Start remains selected and the GeoShift process is alive, the selected location now remains active even if UI monitoring is temporarily delayed. Restore GPS still clears explicitly, and a real process crash still hands cleanup to the worker.

Validation

• 21 Swift tests, including TERM-ignoring timeout and path-with-spaces lease regressions
• 19 Python worker safety tests, including alive/dead/unknown liveness decisions and real flock behavior
• localization plists and shell syntax validated
• gitleaks found no secrets in source, tests, docs, or git history
• packaged app signature verified and installed worker SHA-256 matched source
• live Wi-Fi iPhone check: exact device connected, Belgrade applied, status remained active, heartbeat advanced, and the installed GUI held the liveness lock