fix(dsl): compute cron wait at execution time, not at df.start() time

[Copilot]

Fixes #130.

df.wait_for_schedule() pre-computed wait_seconds at graph construction time. Any delay between df.start() and when the BGW actually runs the WAIT_SCHEDULE node caused the timer to fire early — potentially before the intended cron tick. Worse, in a recurring @> loop the offset was baked once and reused on every continue_as_new iteration, so after the first tick the wait collapsed to ~0 and the loop busy-spun.

Approach

The next cron tick is a function of "now", so it must be computed when the node executes, not at df.start() time. Inside the orchestration we read the current time via ctx.utc_now() — duroxide's deterministic clock, whose value is recorded in history and replayed verbatim — and then do pure cron math against it. This is fully replay-safe (the only non-determinism, the clock read, is the recorded syscall) and needs no extra activity.

This supersedes the earlier draft of this PR, which stored a target_timestamp at DSL time and added a compute_cron_wait activity. That approach was both unnecessary (ctx.utc_now() already gives a deterministic clock read inside the orchestration) and incorrect for recurring loops (the timestamp went stale across iterations).

Changes

• src/dsl.rs — df.wait_for_schedule() now only validates the cron expression eagerly (so a bad expression still fails fast at df.start()) and stores just {"cron_expr": ...}; removed the DSL-time Utc::now() / wait_seconds computation.
• src/orchestrations/execute_function_graph.rs — execute_wait_schedule_node reads ctx.utc_now(), computes the next cron tick from that instant, and schedules schedule_timer(next - now). A NOTE points at duroxide Add pg_durable.worker_role GUC and use -U postgres consistently #34 (absolute-deadline timer) for a future simplification to schedule_timer_until(next).
• src/explain.rs — WAIT_SCHEDULE display is now WAIT '<cron>' (the precomputed (Ns) is gone, since the wait is no longer known at plan time).
• src/lib.rs — unit test asserts the node config keeps cron_expr and contains neither wait_seconds nor target_timestamp.

Config shape change

Before:

{"cron_expr": "*/5 * * * *", "wait_seconds": 142}

After:

{"cron_expr": "*/5 * * * *"}