Wire RecoveryProbeCompleted event (#746)

[ChrisJr404]

Wires up RecoveryProbeCompleted, which was defined back in the telemetry work but never actually emitted, so subscribers can see every yellow probe's outcome without it getting mixed into the general RunCompleted error-rate stream.

It fires from RecoveryProbe#recover, right after the post-probe metrics snapshot and before the still-yellow early return, so it happens on every probe regardless of which color the probe resolves to. There's no dedup guard because it's a per-probe measurement, not a state transition. record_success/record_failure pass the outcome (:success/:failure), the tracked failure (nil on success), and the same snapshot used for the recovery decision as progress.

Duration is the one thing RecoveryProbe can't see on its own, so YellowRunStrategy measures it (it already has clock access from the RunCompleted work) and threads it down. I typed duration_ms as Float? to match RunCompleted#duration_ms — it's nil only when nobody was subscribed at probe start, same race. I also extended the clock-capture guard so it measures when the probe event is subscribed, not just RunCompleted; otherwise subscribing to only RecoveryProbeCompleted would always give you a nil duration.

Tests: added a RecoveryProbeCompleted telemetry group in recovery_probe_spec.rb covering success, tracked failure, that it fires even when the light stays yellow, and that a nil duration passes through. In yellow_run_strategy_spec.rb I added cases for the measured duration reaching the probe and for the probe-only-subscribed path, and updated the existing expectations for the new duration_ms: argument. RBS updated in lockstep.

bundle exec rspec is green (791 examples, 0 failures, with Redis up), steep check clean, rbs -I sig validate clean, standardrb clean.

Closes #746.

[github-actions]

Review price tag

🟢 103 effective lines — about 12–31 min of focused review (based on 200–500 lines/hour). This is within the range where reviewers find the most issues per line, and small changes usually receive feedback the fastest.

Why these numbers?

These minutes are what careful defect-finding costs at 200–500 lines/hour — the rate review studies report, not how long a skim takes. "Effective lines" already exclude generated files and lockfiles. Treat the rates and the 200/400 thresholds as guardrails, not laws.

[ChrisJr404]

Going to withdraw this one. These good first issue tickets should stay open for folks getting their first contributions in — I didn't mean to jump the queue. Closing so it's free for someone who needs the on-ramp. Sorry for the noise.