fix(cron): non-dict schedule no longer freezes the whole scheduler

[necoweb3]

Problem

A job record in jobs.json can have a non-dict value for the "schedule" field (e.g. null, a string, or an old format) when it is created or edited directly, or due to corruption.

In _get_due_jobs_locked:

schedule = job.get("schedule", {})
kind = schedule.get("kind")
...
recovered_next = compute_next_run(schedule, ...)
if kind in {"cron", "interval"}:
    ...

When schedule is not a dictionary, the code crashes with an AttributeError (or TypeError). This aborts the entire due-jobs scan before save_jobs() is called. As a result, healthy jobs lose their fast-forwarded next_run_at values and are never persisted.

This is the exact same failure mode as the recently fixed id-less job bug.

Root Cause

job.get("schedule", {}) returns the actual value when the key exists, even if it is not a dict. Later code assumes schedule is always a dictionary and calls .get("kind") or direct key access (schedule["kind"], schedule["expr"], schedule["minutes"]). There was no early normalization for this field.

Fix

Normalize non-dict schedule values to {} at the very beginning of _get_due_jobs_locked, before any code touches the schedule data. This follows the same approach used for id-less records.

Additionally, added defensive guards in compute_next_run, _compute_grace_seconds, and _recoverable_oneshot_run_at to prevent crashes if a bad schedule somehow reaches them.

Test

Added regression test test_bad_schedule_does_not_crash_or_block_sibling_jobs:

• Creates one job with "schedule": null and one healthy past-due job.
• Verifies that get_due_jobs() does not raise.
• Verifies that the healthy sibling job is still returned.
• The test fails on current main and passes with the fix.

[alt-glitch]

This was generated by AI during triage.

Related cluster (cron/jobs.py malformed-record scheduler freeze) — same failure family as #61382 (id-less job aborts _get_due_jobs_locked before save_jobs()) and closed superset #51267 (per-job try/except quarantine so one bad job can't stall the whole scan); #40740 also guards compute_next_run against non-dict schedules. This PR targets a DIFFERENT malformed field (non-dict schedule) at the same function, so it is complementary rather than a duplicate. Verified on main: line ~1691 does schedule = job.get("schedule", {}); kind = schedule.get("kind"), which raises on a non-dict value and aborts the tick before persistence — the mechanism this PR fixes is real. Maintainer to pick canonical / merge order across #61382, #51267, #40740, and this PR.

[teknium1]

Merged via PR #61723 — your commit was cherry-picked onto current main with your authorship preserved in git log (rebase merge). Thanks @necoweb3! Your schedule normalization landed alongside @hydracoco7's id repair (#61382, the earliest of the cluster) and your #61581 timestamp fix, plus a per-job containment guard that hardens the whole class. Your compute_next_run guards from this PR were kept as the cleaner of the two variants.