#11108: fix(cron): prevent missed jobs from being skipped on timer recompute

## Summary When `onTimer` fires and `findDueJobs` returns empty, the code blindly calls `recomputeNextRuns()` which recalculates all `nextRunAtMs` from the current time. This causes jobs that should have run (but were missed due to timer issues) to be pushed forward, skipping their scheduled executions. ## The Problem 1. A cron job runs successfully, `nextRunAtMs` is set to the next scheduled time 2. The timer doesn't fire on time (due to issues described in #10849) 3. When `onTimer` eventually fires, `findDueJobs` might return empty 4. `recomputeNextRuns()` is called, pushing ALL jobs forward from current time 5. Scheduled executions are silently skipped ## The Fix Before calling `recomputeNextRuns()`, check if any jobs have `nextRunAtMs` in the past. If so, run them first instead of blindly advancing their schedule. Fixes #10849 #10904 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change updates `src/cron/service/timer.ts` to avoid calling `recomputeNextRuns()` when `onTimer()` wakes up late and there are jobs whose `nextRunAtMs` is already in the past. Instead, it scans the store for those “missed” jobs, marks them as running, persists the state, and returns them for immediate execution, preventing silent schedule skips caused by recomputing all next-run times from “now”. <h3>Confidence Score: 3/5</h3> - This PR is close to safe to merge, but has a couple correctness edge-cases in the new missed-job detection path. - The overall approach matches the described bug, but the missed-job predicate is inconsistent with the existing due check (`>` vs `>=`), and the new path omits an existing guard that prevents rerunning already-succeeded one-shot `at` jobs. Both can lead to skipped or duplicate executions in specific states. - src/cron/service/timer.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->