#15754: fix: handle Unix timestamps in seconds in parseAbsoluteTimeMs

## Summary The `parseAbsoluteTimeMs` function in `src/cron/parse.ts` was not correctly handling numeric timestamps that are in seconds (Unix timestamps) vs milliseconds (JavaScript timestamps). This caused cron jobs scheduled with absolute numeric timestamps in seconds to fire at the wrong time. ## Changes - Added a threshold check (10 billion) to distinguish between seconds and milliseconds in `parseAbsoluteTimeMs` - Numbers less than 10 billion are assumed to be Unix timestamps in seconds and are multiplied by 1000 to convert to milliseconds - Numbers greater than or equal to 10 billion are assumed to be JavaScript timestamps in milliseconds and are used as-is - This is consistent with similar logic in `src/providers/github-copilot-token.ts` ## Testing - Ran all 104 cron tests - all passed - Verified the fix handles: - Unix timestamps in seconds (e.g., "1771005600" → 2026-02-13T18:00:00Z) - JavaScript timestamps in milliseconds (e.g., "1771005600000" → 2026-02-13T18:00:00Z) - ISO string timestamps (e.g., "2026-02-13T18:00:00.000Z" → correct parsing) Fixes openclaw/openclaw#15729 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change updates `src/cron/parse.ts` so `parseAbsoluteTimeMs` can accept numeric absolute timestamps provided either as Unix seconds or JavaScript milliseconds. It introduces a `10_000_000_000` cutoff: values below the cutoff are interpreted as seconds and converted to ms; larger values are treated as ms. This function is used throughout the cron scheduling/normalization/validation path (e.g., job creation, store migration, next-run computation), so the fix prevents one-shot `at` schedules supplied as Unix seconds from firing at the wrong time. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minimal risk once the misleading comment is corrected. - The logic matches an existing precedent in the repo (Copilot token expiry parsing) and is narrowly scoped to numeric parsing. The only concrete issue found is an incorrect/misleading comment about what the threshold represents, which could lead to future confusion when modifying the heuristic. - src/cron/parse.ts _{Last reviewed commit: b359dc8} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->