Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

…t dispatch

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

…eave it

Editing a task that had used up its run cap still let the Enabled switch
turn on; Save reported success, but the server keeps capped tasks paused,
so reopening showed it off again. The switch could also show a stale value
when the task paused, or another client changed it, while the editor was
open.

The web and mobile editors now show the live task's enabled state until the
user uses the switch, keep it off and locked while the cap of the schedule
the save will keep is used up, and send enabled only after an explicit
switch action. Raising or clearing the cap therefore keeps a paused task
paused until the user turns Enabled on, and a pause made elsewhere is never
undone implicitly. Mobile also treats an explicit Enabled change as unsaved
work when deciding whether to warn before discarding the editor.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…back, show unpadded times

Two Macroscope findings on the scheduled-task restrictions:

- In a repeated fall-back hour, the restricted interval schedule added the
  interval with calendar arithmetic, which re-resolves the repeated hour to
  its first occurrence. The next run could land before the current time,
  so a window opening inside that hour kept the task due and rescheduled
  on every poll. The restricted path now adds elapsed time, and a window
  opening that resolves before the candidate steps forward on the
  candidate's own offset.
- The contract accepts window times such as "9:00", but the web editor
  passed them unchanged to native time inputs, which only display
  zero-padded HH:mm, so the configured window showed as blank. The editor
  now pads them when it reads a task.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…indow in a fall-back hour

A time window that overlaps a fall-back hour is entered a second time when
the hour repeats. After the first pass through the window ended, the
restricted interval schedule skipped straight to the next day, although
the repeated part of the window was still ahead and the dispatch check
would allow a run in it. The schedule now uses the earliest re-entry later
the same day: the repeated window opening, or the fall-back instant itself
when the window began before the repeated hour (for example 00:30-01:30 in
New York, or Lord Howe's 30-minute fall-back).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>