#16880: fix(cron): respect per-job timeoutSeconds in executeJob path (#16841)

## Summary Fixes #16841 The `executeJob` function (used for missed-job recovery, `runDueJobs`, and manual/forced runs via `ops.ts`) called `executeJobCore` directly without any timeout wrapper. Unlike the `onTimer` batch path which correctly used `Promise.race` with `payload.timeoutSeconds`, jobs running through `executeJob` relied solely on the inner agent timeout from `resolveAgentTimeoutMs`, which defaults to `cfg.agents.defaults.timeoutSeconds` and ignores the per-job `payload.timeoutSeconds` override. ## Changes Added the same `Promise.race` timeout wrapper to `executeJob`, reading `payload.timeoutSeconds` from the job config with `DEFAULT_JOB_TIMEOUT_MS` (10 min) as the fallback — matching the existing `onTimer` behavior. ## Testing - Existing cron tests pass (`service.issue-regressions`, `service.rearm-timer-when-running`) - Linter and formatter pass (oxlint + oxfmt) <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds `Promise.race` timeout wrapper to the `executeJob` function to respect per-job `timeoutSeconds` configuration. Previously, jobs executed via `executeJob` (used for missed-job recovery, manual runs, and forced execution) bypassed the job-level timeout and relied only on the inner agent timeout. This change mirrors the existing timeout logic in `onTimer` (lines 230-245), applying the same `jobTimeoutMs` calculation and `Promise.race` pattern with proper timeout cleanup. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The implementation exactly mirrors the proven timeout pattern from `onTimer` (lines 230-245), uses the same timeout calculation logic, includes proper cleanup via `.finally()`, and maintains consistency across both execution paths. The change is minimal, focused, and directly addresses the documented issue. - No files require special attention _{Last reviewed commit: d29fc2c} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->