#14382: cron: record lastErrorReason in job state

This PR adds `lastErrorReason` to cron job state and populates it by classifying the last error string via `resolveFailoverReasonFromError` (billing/rate_limit/auth/timeout/format). Motivation: groundwork for reason-aware cron guardrails (#14376). Today cron backoff is consecutive-error based but reason-agnostic; surfacing the classified reason improves observability and enables policy decisions in follow-up changes. Changes - Add `lastErrorReason?: FailoverReason` to `CronJobState` (types + gateway schema). - Populate `job.state.lastErrorReason` when a job run ends in `error`. Notes - This PR does **not** change scheduling policy/backoff behavior yet; it only records the reason. - Lint passed; targeted tests run for failover-error classification. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds a `lastErrorReason` field to cron job state, wires it into the gateway cron schema, and populates it in the cron timer service by classifying the last error string via `resolveFailoverReasonFromError`. The change fits into the existing cron state tracking (lastStatus/lastError/lastDurationMs/consecutiveErrors) by providing a structured reason alongside the raw error text, enabling future reason-aware guardrails without changing current backoff policy. <h3>Confidence Score: 3/5</h3> - This PR is close to safe to merge but currently contains a definite TypeScript module syntax error. - The core logic change is small and localized, but `src/cron/types.ts` places an `import` after other statements, which will break parsing/compilation until fixed. - src/cron/types.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->