Make CoreLocation geolocation resilient to cold starts

[thornjad]

Work Done

When CoreLocation failed on a cold start (e.g. right after wake-from-sleep, before WiFi positioning is ready), location resolution fell back to coarse IP geolocation. That fallback can land far enough from a configured Tempest station to trip the station proximity gate and silently disable Tempest enrichment — and because the resolved location was cached for the whole server lifetime, a single cold-start miss pinned the entire session to the wrong location.

• The CoreLocation helper now waits for a real fix instead of giving up on the first attempt: startUpdatingLocation rather than one-shot requestLocation, a 30 s budget, kCLErrorLocationUnknown treated as transient, and an accuracy gate so a stale coarse fix isn't accepted.
• A failed lookup is cached for only 120 s (a successful one for an hour), so a cold-start miss self-heals on a later call once locationd is warm, rather than pinning the session to the IP fallback.
• The compiled helper is now rebuilt when its source changes, keyed off a source hash — previously a stale cached binary was reused indefinitely.

Testing

• Given a configured Tempest station with ENABLE_CORELOCATION=true
• Delete ~/Library/Application Support/stormscope/StormscopeLocation.app to force a clean build
• Call get_conditions with no coordinates
• Expect the helper to recompile and a fix to return, and the response data_source to read tempest
• Confirm ~/Library/Application Support/stormscope/StormscopeLocation.app/Contents/.swift-version now exists
• Edit the Swift source, call get_conditions again
• Expect the helper to rebuild rather than reuse the old binary