Fix launch crash: start telemetry after Core Data initialization

[trioneer-dev]

Problem

Debug/simulator launches of current dev crash within seconds:

NSInternalInconsistencyException: This NSPersistentStoreCoordinator has no persistent stores (unknown). It cannot perform a save operation.

Crashing queues are NSManagedObjectContext: storeGlucose and storeBatteryStatus.

Cause

Since #1367, TelemetryClient.shared resolves through the DI container with eager injectServices. AppDelegate.didFinishLaunchingWithOptions calls it at launch, which resolves APSManager + FetchGlucoseManager and thereby constructs BaseDeviceDataManager — the whole APS/device graph — before CoreDataStack.initializeStack() has finished loading the persistent stores.

The CGM and pump simulators deliver status/readings immediately on construction, so their first Core Data save races the store load and aborts the app. Real hardware usually wins the race (BLE reconnect latency), which is why reports cluster on simulator-configured dev setups; a Debug/TSAN build widens the window further. The launch-order log signature: a healthy launch logs Successfully loaded persistent store before PumpManagerState is persisted; a crashing one persists PumpManagerState immediately and never reaches the store-load line.

Fix

AppDelegate no longer resolves services at launch (only the Crashlytics gate remains, which touches plists only). Telemetry starts at the end of TrioApp.loadServices() — i.e. strictly after Core Data initialization — with the identical cadence sequence as before (install ID, cold-launch recording, SHA-change ping, recurring timer, overdue check). The foreground-transition hook receives its TelemetryClient reference from loadServices() and no-ops before that.

This deliberately does not reintroduce the old injectIfNeeded deferral; eager injection stays, only the call site moves behind the initialization barrier.

Notes

• Cold-launch timestamps are now recorded ~1 s later (post store load) — immaterial to the 7-day sliding window.
• A latent same-class race remains on the APNS path (TrioRemoteControl.shared in didReceiveRemoteNotification when a push cold-launches the app). It predates Refactor: Dependency Injection Hygiene #1367 and is left for a follow-up.

[jwoglom]

Cherry-picked this onto latest dev and validated it doesn't crash on startup

[LiroyvH]

Can confirm this works in a build to iPhone 16 Pro and iPhone 12 Mini, both running iOS 27 stable and built from XCode 27. Appears to build as expected and the app now launches instead of crashing. This is not a full test of the dev branch latest state, just confirming that the app no longer fatally crashes when building this branch as compared to the current dev branch where it does fatally crash.

[bjornoleh]

Confirmed that the app on my phone no longer crashes when running this update. Did previously crash with current dev with sim pump/CGM.

Approving based on a quick, successful test.