fix(api): wake scheduler — missed-wake recovery, retry consolidation, status surface

Bugs fixed
- Missed wakes silently lost. The old loadScheduleFromDB just pushed any
  past next_wake_at to its 'next occurrence' in *server* local time, so a
  wake that fired while the API was down never ran — defeating the whole
  point of the panel (overnight task picks up after a 5h rate-window
  reset). Now: if missed by <= 2h we fire it on the next tick; either way
  the entry is rolled forward by 24h-multiple steps.
- Server-TZ drift. nextOccurrenceAt15 used the server's local TZ, so on
  a UTC Docker host running for a user in PST the reschedule slowly
  migrated the fire time. Now we advance by 24h * N from the original
  client-supplied timestamp, preserving the user's wall-clock intent.
- Retry storm. Every failed wake pushed a new entry into a retries[]
  array, all converging at the same +5min instant. Replaced with a single
  shared pending-retry slot whose budget resets on subsequent failures.
- Retry race with fresh fires. If a tick fired AND a retry was due in
  the same iteration we'd double-hit the upstream. Now retries only run
  on ticks where no fresh wake fired.

New behavior surfaced on /wake-schedule:
  { schedule, resetOffsetHours, lastWake, pendingRetry }

POST /wake-schedule/toggle now also rejects non-integer hours (4.5, etc.)
and returns the same snapshot shape so the client can stay in sync.

Tests: 9 new HTTP route tests covering snapshot shape, add/remove,
validation (range, integer, past timestamp, missing timestamp), and
independent multi-hour scheduling.

0 files changed, 0 insertions, 0 deletions