services/hrm: enforce serve deadlines without reports

[jplexer]

A silent HRM driver could keep periodic sampling running indefinitely because the unserved timeout was evaluated only on driver reports or unrelated state changes. Keep the manager's existing timer active for due, expiry, and unserved deadlines, so missing reports cannot bypass the cutoff.

Compute deadlines from existing timestamps so poor readings and unrelated updates do not extend the window. Timer callbacks reevaluate current state on KernelBG, respecting charging, run-level and preference gates, subscription renewal, and optical-path changes. Preserve continuous live/workout sampling and existing deferral timing. Remove expired subscriptions during the locked update pass so silent expiry also releases their allocations.

Fixes FIRM-4328

Validation:

• All 42 HRM tests pass. Coverage includes silent-driver timeout/backoff, fixed deadlines, tick-zero activation, activity interval changes, stale callbacks, gates, optical-path scheduling, and expiry/allocation cleanup.
• The silent-driver regression fails before the fix.
• Activity, workout, and health test suites pass.
• Normal Obelix PVT firmware builds with GH3X2X, HRV, Moddable XS, and speaker support enabled.
• Formatting, gitlint, and git diff --check pass.

Hardware confirmation on the reporter's watch remains outstanding.

[gmarull]

This pass now frees expired subscriptions even while the sensor is off/silent, but HRMEvent_SubscriptionExpiring is only sent from the data path (hrm_manager_new_data_cb / prv_system_task_hrm_handler), so the holder never gets the event first.

Kraepelin (walk/run hrm_session, 10 min expiry) and workout_service keep their now-dangling session refs. The next sys_hrm_manager_set_update_interval() on that ref returns false, and since the ref isn't HRM_INVALID_SESSION_REF the caller never re-subscribes: kalg_activity_hrm_active() keeps reporting true and activity HR never resumes. Before this change an expired-but-unreported session stayed in the list and a later set_update_interval revived it.

Either send the expiring event here before freeing, or keep the previous semantics for silent expiry.

[gmarull]

After a transient hrm_enable() failure (attempt 1 of HRM_MAX_ENABLE_FAILURES), the sensor is off with remaining_ms <= 0, so the timer is stopped here. With the sensor off no reports arrive either, so nothing triggers another pass: due subscribers (e.g. daily HR logging) can go unserved for hours, and the failure counter never reaches its limit because no further attempts happen.

Avoiding a busy retry makes sense, but this should re-arm with a backoff (e.g. after HRM_SENSOR_SPIN_UP_SEC) rather than stop.

[gmarull]

The serve window is measured from the sensor's global on-time (sensor_on_since_ticks), not per subscriber. If a continuous reader (BLE HR relay, workout) has kept the sensor on > 120 s, a periodic subscriber that becomes due is marked served immediately (line ~496) without a single sample.

E.g. switch the activity SpO2 session to features=SpO2 while a workout is running: its stale last_valid_bpm_ticks gives age >= interval + unserved, serve_window_expired is already true, so it gets last_valid_bpm_ticks = cur_ticks before the path is selected and the SpO2 window is skipped with no IR measurement. The new timer now enforces this deadline even without reports, so it's more likely to hit.

[gmarull]

While the gate is closed (charging, run level, prefs off) the timer is stopped, so expired subscriptions aren't freed until the gate reopens, despite the goal of releasing allocations on silent expiry. E.g. an app exits with a 5 min cleanup expiry and the watch goes on the charger for hours: the HRMSubscriberState stays allocated (and the ref still resolves) until unplugged or some unrelated event runs a pass. Consider still arming for the nearest expire_utc when the gate is closed.

[gmarull]

This loop duplicates the per-subscriber deadline math of the main pass in prv_update_hrm_enable_system_cb (age, interval, spin-up, unserved window, expiry, prefs filter), which must be kept in sync by hand; a drift means arming the wrong deadline (1 ms busy re-arm via MAX(1, ...), or a missed unserved cutoff). It also re-reads rtc_get_time/rtc_get_ticks/prv_prefs_allowed_features and walks the list a second time. Folding the serve and expiry deadlines into the main loop's remaining_ticks and arming from that single value would be simpler.

[gmarull]

Two things on this conversion:

• It truncates, so the timer can fire just before the tick-based >= check in the main pass is met: serve_window_expired is false, the reschedule computes a 0/1-tick deadline and MAX(1, ...) arms a 1 ms timer for another full locked pass on KernelBG. Round up instead.
• It hand-rolls ticks→ms with RTC_TICKS_HZ on a pbl_ms_to_ticks() value; it's only correct due to the PBL_TICK_HZ == RTC_TICKS_HZ static assert. The main pass already uses pbl_ticks_to_ms(); please use that (clamped to int64).

[gmarull]

This removal loop duplicates the walk-and-free in hrm_manager_new_data_cb (expired_state / prv_remove_and_free_subscription), and it makes the if (state->expire_utc && utc_now >= state->expire_utc) continue; check in the main loop below (~line 466) dead within the same locked pass. A shared prv_remove_expired_subscriptions(utc_now) helper used by both paths would remove the duplication and the dead check.