#12443: fix(cron): don't advance past-due jobs that haven't been executed

## Summary Fixes #12440 When `recomputeNextRuns()` is called (e.g., via `cron list`/`status`), it was advancing past-due jobs to the next occurrence without checking if the job was actually executed for that time slot. This caused jobs to be skipped entirely if `cron list`/`status` was called after the scheduled time but before the job ran. ## Fix Only advance `nextRunAtMs` if the job was already executed for the current time slot (`lastRunAtMs >= nextRunAtMs`). Past-due jobs that haven't been executed are left alone so `runMissedJobs` or `findDueJobs` can pick them up. ## Testing 1. Create a cron job scheduled for a time in the near future 2. Wait for that time to pass 3. Run `openclaw cron list` before the job executes 4. Previously: `nextRunAtMs` would advance to the next day, job skipped 5. With fix: `nextRunAtMs` stays at the past-due time, job runs normally <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change updates `recomputeNextRuns()` in `src/cron/service/jobs.ts` to avoid advancing `nextRunAtMs` for past-due jobs unless the job has already been executed for that scheduled slot (`lastRunAtMs >= nextRunAtMs`). The intent is to prevent `cron list` / `cron status` (which call recomputation) from skipping jobs that are due but not yet executed. The update integrates with the existing scheduler flow in `src/cron/service/timer.ts`, where `findDueJobs`/`runMissedJobs` rely on `nextRunAtMs` remaining past-due so jobs can be picked up and executed. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge and fixes the reported job-skipping behavior, but verify next-run recomputation remains correct after schedule changes and other state edits. - The core change is small and targeted, and it aligns with how `findDueJobs` / `runMissedJobs` detect due work. Main remaining concern is whether any code paths depend on `recomputeNextRuns()` to refresh `nextRunAtMs` for future (non-missing) values; if so, stale `nextRunAtMs` could persist and cause incorrect scheduling. - src/cron/service/jobs.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->