Add per-routine target heart rate with live in-run indicator

Endurance routines (HIIT, cardio, cycling) can carry an optional target bpm
(RoutineDocument.targetHeartRate, not schema-bumped — same preference-field
rationale as restSeconds/autoAdvance), snapshotted onto the WorkoutDocument at
plan time like the other pacing fields.

During a run, the watch streams its live HR sample to the phone over a new
best-effort liveHeartRate message — deliberately outside the LiveProgress
machinery (no version bump, no staging/retry; a gauge, not a record), throttled
to changed-bpm-or-10s in the watch bridge. LiveRunState holds the sample with a
30s staleness auto-clear so a dead stream never shows a frozen number.

Both run screens show the reading only when the run carries a target: the
phone's ExerciseProgressView as a top pill, the watch's in the top-trailing
toolbar slot, each tinted by a shared ±5 bpm HeartRateBand with an arrow cue to
push harder (low) or ease off (high) — e.g. dialing in a treadmill incline to
hold a steady effort.

Claude-Session: https://claude.ai/code/session_01Y7ZhkCYWNiTSAFhFCGnJ8n

Workouts Watch App/WatchAppServices.swift

@@ -36,6 +36,9 @@ final class WatchAppServices {
         self.sessionCoordinator = coordinator
         // weak break: the coordinator is held here; the bridge only borrows it.
         bridge.onWorkoutsChanged = { [weak coordinator] in coordinator?.reconcile() }
+        // Forward each live HR sample to a mirroring phone (best-effort, display-only).
+        // No cycle: the bridge never references the session manager back.
+        sessionManager.onHeartRateSample = { [bridge] bpm in bridge.sendLiveHeartRate(bpm) }
         bridge.activate()
         // Seed `previouslyActiveIDs` from whatever the bridge already applied at launch, so the
         // first real change is measured against a correct baseline (and the launch race — a