ncl tasks update --recurrence doesn't recompute the next scheduled fire (process_after)

Summary

Changing a task's cadence via ncl tasks update --recurrence <new-cron> doesn't recompute when the task next fires — process_after stays whatever it was on the OLD schedule. E.g. switching a task from weekly to daily leaves it still scheduled for its next weekly slot; the caller has to separately, manually compute and set --process-after to get the new cadence to actually take effect immediately.

Confirmed via source

src/cli/resources/tasks.ts, updateTaskCommand (~line 347, 354):

if (args.process_after !== undefined) update.processAfter = parseProcessAfter(args.process_after, tz);
...
update.recurrence = recurrence;

These are two fully independent field assignments — setting recurrence alone never touches processAfter, and there's no derived recomputation (e.g. "next fire = now + new interval") anywhere in this path.

Impact

Real install: switched a task from weekly to daily, confirmed via ncl tasks get that recurrence updated correctly, but the task didn't actually fire daily until process_after was separately bumped by hand. Anyone changing a task's cadence without knowing this quirk gets silent no-op behavior — the update "succeeds" but nothing changes until the next already-scheduled fire, which could be days away on a cadence change from a slower to faster schedule.

Suggested fix

Either:

1. When --recurrence is set without an explicit --process-after, recompute process_after from the new recurrence (e.g., next occurrence from now), so a cadence change takes effect immediately by default; or
2. If that's not always the right default (a caller might want the new cadence to start from the existing next-fire time), at minimum document it in the command's own --help/description text, so this isn't discovered by observing a task silently not fire per its new schedule.

Not already covered

Searched open issues for "recurrence" + "process_after" — nothing found addressing this specific interaction.