Heart-rate home-screen widget: live bpm with the recent trace #1957

A home-screen widget showing the live heart rate with recent history as a trace:
the current bpm, a min/max for the window, and a sparkline with a bpm scale and
time labels.

The existing widgets carry heart rate as a NUMBER only (the 2x2 score widget and
its compact twin). The number alone does not say whether 69 is a resting evening
or the tail of a climb, which is the thing a glance is for.

Shape

• current bpm, dimmed when it is a carried-over reading rather than a live sample
  (the existing [HrDisplay] rule, unchanged)
• min and max across the shown window
• a trace of the last few hours, with a bpm scale and time labels
• an "updated" stamp, since a widget is always behind the Live screen

The constraint worth recording

Glance compiles to RemoteViews, which has no Canvas. A sparkline cannot be drawn
by a composable at all; it has to be rendered to a Bitmap and handed over as an
Image. That splits the work in two: everything decidable without a Canvas
(retention, normalisation, tick choice) belongs in a pure, unit-tested half,
because a Bitmap is not something a JVM test can assert about.

RemoteViews also carries its payload over a Binder transaction with a hard size
limit, and a widget that exceeds it does not degrade — it fails to render. So the
bitmap needs a cap.

Data

No new source is needed. WidgetSnapshotStore already receives a live HR on the
app's own cadence, throttled by PushGate to about once a minute, which is a
natural bucket size for a trace. The series can be folded in by the store itself
so no producer has to learn about it.

iOS

Deliberately not in scope here. WidgetKit is SwiftUI and can draw the trace
directly, so the renderer will not port, but the retention rule and the tick
choices are the same decisions and should be shared rather than made twice.