#11857: fix: recompute stale cron nextRunAtMs on gateway restart

## Summary After a gateway crash or extended downtime, persisted `nextRunAtMs` values may be stale but still in the future. `recomputeNextRuns()` skips jobs with future `nextRunAtMs`, causing multiple scheduled runs to be silently missed until the stale value is reached. - Add a `force` option to `recomputeNextRuns()` that bypasses the "still-future" guard - Use `force: true` in `start()` so all enabled jobs get their `nextRunAtMs` recalculated from the cron expression on every gateway restart Closes #11835 ## Test plan - [x] Added test: "recomputes stale future nextRunAtMs on restart after extended downtime" - Simulates a job with `nextRunAtMs` set 2 days in the future after a crash - Verifies that on restart, `nextRunAtMs` is recomputed to the correct next occurrence - [x] All 88 existing cron tests pass (20 test files) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds a `force` option to `recomputeNextRuns()` so the cron scheduler can bypass the “nextRunAtMs is still in the future” guard. On gateway startup (`start()`), it now calls `recomputeNextRuns(state, { force: true })` to recompute `nextRunAtMs` from the cron expression even when persisted values are stale-but-future after a crash/extended downtime. A new restart catch-up test simulates persisted `nextRunAtMs` being incorrectly far in the future and verifies that on restart the job’s `nextRunAtMs` is recalculated to the next expected occurrence. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - Core change is small and targeted: adding an optional `force` flag and using it on startup to recompute stale persisted schedules; behavior is covered by a new focused test and existing cron tests are reported passing. Only issue found is a misleading comment in the new test. - src/cron/service.restart-catchup.test.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->