TestFlight diagnostic build: HealthKit logging + permission fixes

[gsbernstein]

Purpose

TestFlight diagnostic build for a tester who cannot load HealthKit sleep data. Adds local logging with a share/copy flow in Settings — no third-party analytics.

Now merged up to date with master, which independently rewrote HealthKitManager to use HKSampleQueryDescriptor / HKSourceQueryDescriptor with proper awaiting (#40), added an observer query with background delivery, and already carries the SwiftData store-reset recovery. All of that is kept; the diagnostics layer is re-applied on top.

What this adds

• DiagnosticLogger — in-memory log (capped at 500 entries) covering ModelContainer open, HealthKit availability and authorization, sample queries, source discovery, sample processing, and permission state transitions.
• Settings → Diagnostics — live HealthKit state, sample and log counts, plus Share Diagnostic Logs, Copy Logs to Clipboard, and Retry HealthKit Access (which also reloads available sources).
• requestAccessFromUser() — backs Grant Access and the Settings retry. Unlike requestAuthorization(), it always re-presents the HealthKit prompt instead of short-circuiting once the app has asked before, shows a spinner, and surfaces errors. When the reload returns zero samples it points the user at Settings → Health → Data Access & Devices.
• SharePresenter — presents UIActivityViewController from the topmost view controller. Nesting a SwiftUI .sheet inside the Settings sheet caused the share sheet to dismiss itself and take Settings with it.

For the tester

1. Install this build from TestFlight
2. Open the app and tap Grant Access (or Retry HealthKit Access in Settings)
3. Go to Settings → Diagnostics
4. Tap Share Diagnostic Logs or Copy Logs to Clipboard
5. Send the logs over

Reading the logs

• requestAuthorization returned followed by rawSamples=0 suggests read access is denied — check Settings → Health → Data Access & Devices → Bedger → Sleep
• Sleep sample query failed: … is an actual HealthKit error with its message
• Discovered N sources with N > 0 but 0 sessions after filtering points at source exclusions or sleep-stage parsing

Note

ContentView still inserts UserPreferences from a computed property read during body evaluation (inherited from master). That is a latent SwiftUI/SwiftData issue, not the cause of the reported crash — the crash log pointed at the ModelContainer fatalError, which master now recovers from. Worth fixing separately against current master.