Sentry: iOS killed-in-background heuristic (Phase 7b, optional)

Part of #74. Optional, independent.

Spec: docs/sentry-integration-plan.md Phase 7b.

iOS only tells us "why was the app killed" as 24-hour aggregate counts (Apple's MetricKit reports), with no timestamps. This workblock adds a simple heuristic for per-incident detail: record the app's lifecycle state on disk as it changes, and on the next launch, if the previous run didn't end cleanly, report one "ios kill inferred" event saying whether the app was in the background and roughly how long it had been there.

Deliverables

• ios/AppKillHeuristic.swift: write background / foreground / terminated-cleanly plus a timestamp to on-device storage on each lifecycle change. On cold start, an unclean previous state produces one event tagged ios.killed_in_background, with last_known_state and time_since_last_state_ms
• Refresh the marker every 30 seconds while the app is in the foreground, so the "how long" number doesn't badly understate
• Document the limits honestly: this catches any unclean end — the system killing the app to free memory, iOS killing an unresponsive app, user force-quit, OS reboot, or a crash. The MetricKit counts and crash reports help tell those apart on dashboards

Tests

• AppKillHeuristicTests.swift with a fake store + clock: a clean shutdown suppresses the event; a stale marker fires once then clears; foreground vs background drives the tag correctly
• Manual check by forcing a low-memory kill

Start with Phase 7b in docs/sentry-integration-plan.md, then inspect ios/AppKillHeuristic.swift and the iOS lifecycle integration points. Use AppKillHeuristicTests.swift with a fake store and clock to verify clean shutdowns, stale-marker clearing, and foreground/background tagging. Done means the marker is refreshed in the foreground, inferred events report the required fields, and the documented limitations are honest.