Edit cron jobs in a modal with live schedule validation

[ramonski]

Context

Two problems with cron editing, in one feature:

1. The pencil opened an inline per-card form, inconsistent with how task and clock time entries are edited (a modal). Follow-up to Edit every time entry through the shared modal, with notes preview/edit tabs #236/Unify the notes indicator across tasks and clock entries #239/Edit a clock entry's description from its popup #240.
2. Cron schedules had no validation. A typo like 06 45 * * * (hour 45) was silently accepted, never ran, and — combined with Skip cron jobs with invalid schedules instead of 500-ing every cron mutation #243 — bricked every cron mutation.

What changed

Modal editor. The pencil now opens a CronJobDialog (mirrors TimeEntryDialog) holding schedule, model, output, timeout, cloud flag, and the prompt, saved together. The expanded card becomes a read-only prompt preview with an Edit button. Inline field/prompt editing is removed.

Live schedule validation. The schedule field validates as you type against the same APScheduler CronTrigger that actually schedules jobs, so the verdict never drifts from runtime behaviour:

• valid → previews the next 3 fire times under the field
• invalid → shows the error, marks the field red, and disables Save

New POST /api/cron/validate-schedule powers the live feedback; POST/PATCH also reject an invalid schedule (400) as a backstop. Both the modal and the add-job form use the shared ScheduleField.

Shared cron field bits (MODEL_DATALIST, fieldCls, OutputSelect, ScheduleField) moved to cronFields.tsx so the dialog and CronView reuse them without an import cycle.

Verified

Drove the real app (source backend + Vite): modal opens with correct values (the stale-timeout symptom is gone), invalid schedule shows the error and blocks Save, valid edit previews next runs, saves persist, and reopening shows fresh values. Backend suite: 841 passing (4 new schedule-validation tests).

Notes

• APScheduler numbers day_of_week 1 = Tuesday (not Monday as in standard crontab). The preview surfaces this faithfully — it shows exactly when a job will fire. Pre-existing semantics, now visible instead of surprising.
• Depends on nothing in Skip cron jobs with invalid schedules instead of 500-ing every cron mutation #243, but both harden the same invalid-schedule class.