Fire the resting-HR drift alert that was only ever declared

[ak710]

Closes #112

Merge order: 2 of 9. Branches off main, independent of #120.

What

restingHRDrift has been a CoachAnomalyKind since the proactive-alert path landed, with a comment explaining why nothing raised it: the detector reads a 12-hour packet, and drift needs a multi-day baseline. But RestingHRBaselineService already learns and persists that baseline — it just never reached the packet.

Design notes

• Both sides are measured the same way — the interpolated 10th percentile, sharing RestingHRBaselineService's own helper (made internal, with the percentile constant named). Comparing a night's mean against a 30-day percentile would produce a difference that is mostly an artefact of the two formulas.
• The night is bounded by the sleep session, not a fixed clock window, so a late night or a shift schedule is measured over the hours actually slept.
• Fires at +5 bpm, upward only. A resting HR below baseline is usually good news and not worth an unprompted alert.
• Gates: established baseline, ≥10 overnight samples, night ≤2 days old. The sample floor is 10 because a YCBT ring floors its all-day interval at 30 minutes — a full night is only ~14 samples there, against ~84 on a 5-minute Colmi.
• Ordered last of the three detectors. A short night usually raises resting HR too, so when both trip the sleep alert names the cause while this would only restate its consequence.

Docs

docs/project/anomaly-alerts.md is new and documents all three detectors — the two that were already shipping were undocumented.

Testing

PulseLoopTests/RestingHRDriftTests.swift — 11 tests covering the threshold knots, both precedence cases, and the builder's percentile/sample-floor behaviour. Full suite green (882).