R8 re-review M3. Since D4b a running service stays owed until its gateway is ready, and
`update_pause_record.recover()` runs before every non-update command: each launch re-claimed the
debt and waited the full 60 s readiness budget (+2 s confirm), with no backoff, for as long as the
service's gateway stayed unhealthy.
- A recovering launch (`token["recovery"]`) probes readiness for 5 s; the 60 s wait stays with
`hermes update`.
- A service found running but unready records `service_retry` {attempts, next_at} on the token
(60 s, doubling, capped at 1 h). A recovering launch inside that window skips a still-running
service at once and keeps it owed; a stopped one is still started. Success clears the entry.
Test (native Windows, real SCM service whose gateway never comes up, two real recovering
launches): test_a_launch_recovering_an_unready_service_keeps_the_debt_without_stalling.
(cherry picked from commit 823c214534e5f8d301097c063cfc79ebbfddc13c)
76afc136f3