fix: report stable no-now due time correctly

[ByBrawe]

Summary

• make stable /loop-status count the first --no-now interval from createdAt when immediate === false
• keep explicit run-now requests due immediately and normal subsequent runs based on lastRunAt + interval
• add a deterministic command-handler regression for the first delayed interval
• regenerate committed src/index.js from the updated stable source
• harden one Windows comprehensive safety assertion to poll for the scheduler-written safe_shell_blocked state instead of assuming a fixed 400 ms runner delay

Why

PR #107 fixed the scheduler so --no-now delays the first run until createdAt + interval, but stable /loop-status still calculated from lastRunAt || 0. A fresh delayed job could therefore display due in 0s even though the scheduler correctly intended to wait for the first interval.

The V2 status path already follows the correct first-interval semantics; this brings stable status reporting into parity without changing scheduler behavior.

During exact-head Bundle Gate validation, Windows real-host and the normal Windows CI suite passed, but the source-built bundle regression hit a timing-only comprehensive assertion: it read the rm -r -f safety state before the idle-safe scheduler had persisted safe_shell_blocked. The test now uses its existing bounded waitForValue helper for that state, preserving the safety assertion while removing runner-speed dependence.

Scope

Status display correctness, generated stable bundle synchronization, and deterministic test timing. No scheduling semantics change.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.