Sleep onset detection on watchOS: viable non-workout paths and CMSensorRecorder behavior

I'm building a sleep tracker for couples — the headline feature is a notification to your partner the moment you fall asleep (and another when you wake up), detected on the Apple Watch from accelerometer and heart-rate data. The detection has to happen within minutes of onset for the product to make sense.

My setup

• HKObserverQuery on heart rate with enableBackgroundDelivery(.immediate), re-registered on foreground.
• WKApplicationRefreshBackgroundTask rescheduled every 15 minutes.
• CMSensorRecorder.recordAccelerometer(forDuration: 12 * 3600) re-armed on every wake.
• A van Hees-style stillness classifier reading the last ~35 minutes of the buffer, with heart rate as a soft confirmer.
• HealthKit and Motion & Fitness authorized on both iPhone and watch.
• The observer's completionHandler() is called on every branch and the handler stays well under the 15-second watchdog.
• No HKWorkoutSession as my app is not a workout.

Questions

• Is CMSensorRecorder paused or deprioritized while the Apple Watch's automatic sleep detection has classified the user as asleep?

  On a worn watch with the recorder armed for 12 hours, accelerometerData(from:to:) over a 35-minute window inside the auto-detected sleep period returns zero samples. The exact same call an hour later, once the watch has decided the user is awake, returns roughly ten thousand samples for an equivalent window. The user never activated Sleep Focus or Theater Mode — the only sleep-related state at play is the watch's own automatic detection, the same one that writes Core / REM / Deep stages into Apple Health. Is this documented power management I missed, or is it unexpected? Happy to file Feedback with a sysdiagnose during the window if you confirm it shouldn't behave this way.

• Is there a sanctioned non-workout path on current watchOS for detecting sleep onset within a few minutes of it happening?

  A full night recently produced a five-hour stretch with zero observer callbacks and zero background-refresh deliveries between bedtime and wake. The historical guidance to third-party sleep apps has been to reconstruct nights post-hoc from sleepAnalysis samples rather than attempt live detection. Is that still the recommendation today, or is there an API I've missed that would give an onset-focused app tighter wakes around bedtime?

• What is the current App Store review stance on HKWorkoutSession for sleep tracking?

  Would an app that auto-starts a .other / indoor workout only when its own classifier detects pre-sleep signals at the user's typical bedtime, ends the session as soon as onset is confirmed, never starts one outside that gated condition, and explicitly discloses "sleep tracking via workout session" in the App Store metadata — be an acceptable pattern, or grounds for rejection regardless of disclosure?