Friendlier cron-schedule entry (deferred from #134) — decide the UX

[Sootopolis]

Context

#134 shipped wall-clock cron triggers for JobSchedule — but the cron path requires the user to know 5-field unix cron syntax. The interval path (--interval-hours) needs none. This issue tracks whether/how to soften the cron path. Not started — needs a UX decision first.

A prototype of two ideas (Vixie macros + a next-fire preview) was built on the #134 branch and reverted before merge (we wanted to decide the UX deliberately rather than ship the first thing). It's fully described below and trivially reconstructable.

The realisation that prompted deferral

Macros only help the trivial midnight-aligned cadences. The common real schedule — e.g. StatsApp every Monday 15:00 covering the previous week (15:00 Mon = ~15h after the Sunday-midnight week-end, a buffer for Chess.com to settle its data) — needs a real cron string (0 15 * * MON) regardless. So macros buy little; the confirmation that a typed cron fires when intended is the more valuable lever.

That use case is already fully covered by core #134:

ccas schedule add --kind Stats --club <slug> --cron "0 15 * * MON" --tz <zone> --misfire catch_up

(catch_up is right here: a late run over last week is still valid if the server was down at 15:00.)

Options (evaluated)

1. Vixie macros — @hourly @daily @midnight @weekly @monthly @yearly @annually, expanded to 5-field before normalize. Low value — only midnight-aligned cadences; any specific time/day defeats them.
2. Next-fire preview — after schedule add, print the next N wall-clock fire times so the user confirms intent (fires next: Mon 2026-07-06 15:00, …). Highest value — anti-footgun for "did my cron mean what I think". Open sub-decision: printed line (non-interactive, scriptable) vs [Y/n] confirm vs --dry-run.
3. Cron hints in --help — cheapest; the --cron help already carries one example ('0 9 * * MON'); could add a small table. Good ROI, no new code paths.
4. Mini-wizard — bare ccas schedule add prompts how-often → time → tz → misfire. Overlaps the TUI direction (Interactive TUI front-end for CCAS (full-screen, beyond ccas config) #125). Most work.

Prototype that was reverted (reference for re-implementation)

• ScheduleTrigger.macros: Map[String,String] + expansion at the top of normalize (case-insensitive; @weekly → 0 0 * * SUN using the named day to avoid cron4s dow-numbering ambiguity). Each expands to 5-field, then the existing seconds-prefix + ?-day-rule normalization applies. Verified cron4s parses every expansion.
• ScheduleTrigger.nextFires(normalized6, zone, from, count): List[ZonedDateTime] — pure, via cron4s expr.next + List.unfold.
• CLI Dispatcher.printNextFires — best-effort non-interactive preview printed after a successful cron create, locale-pinned EEE yyyy-MM-dd HH:mm.
• --cron help extended to name the macros.

Recommendation

Lean: #3 (help hints) + #2 (next-fire preview); skip #1 (macros) unless a concrete need appears. Decide the preview's interaction model before building. #4 rolls into #125 if pursued.

Relationship

• Follows Wall-clock (cron) job schedules, not just interval #134 (cron triggers).
• Preview UX overlaps the interactive-TUI direction (Interactive TUI front-end for CCAS (full-screen, beyond ccas config) #125).

[Sootopolis]

Core cron triggers shipped in #141 (squash-merge 45a7623 on main). This issue tracks only the friendlier-entry layer (macros / next-fire preview / help hints); the reverted prototype is described in the body above.