fix(workflow): reject over-long delay durations at definition time

[aeonbilal]

Summary

• validate delay durations in WorkflowDef::validate() instead of leaving them to the executor
• reject durations over the 270s cap, and durations that don't parse, at definition time
• move MAX_DELAY_SECS out of the executor's match arm so schema and executor share one definition
• fix the doc comments, which used "5m" and "1h" as examples even though both are over the cap

Why

validate() had no arm for action definitions, so a delay step's duration was never checked when a workflow was saved. The executor caps a delay at 270s (executor.rs), while the field's own doc comments gave "5m" (300s) and "1h" (3600s) as the examples. A workflow copying either one validated, saved, showed as enabled, then failed at the same step on every run, with the only signal being a run-time error the user has to go looking for.

parse_all_action_types pinned the broken case: it asserted that a definition with duration: 5m parses successfully.

The schedule trigger already validates this way. The interval branch calls parse_duration_secs and rejects sub-60s intervals with a comment explaining the runtime constraint behind it. This adds the same treatment one arm over.

Fixes #3021

Notes

• Unparseable durations were also a run-time-only failure. They're rejected at save time now too.
• The error messages name the step id, since a workflow can have several delays.
• I left the 270s value alone. If the intent is that long delays should work, that's the scheduled resume pattern the executor comment mentions as WF-09, and a much bigger change. Validating at save time is worth having either way so nobody stores a workflow that can't run.
• MAX_DELAY_SECS is pub(crate), matching parse_duration_secs next to it, which schema.rs already uses.

Verification

• cargo test -p buzz-workflow — 152 passed, 0 failed
• cargo clippy -p buzz-workflow --all-targets -- -D warnings — clean
• cargo fmt --check -p buzz-workflow — clean

New tests cover rejection at 5m / 1h / 271s, acceptance at 30s / 4m / 270s (the boundary), and rejection of an unparseable duration.