[addadi]

Fixes #34
Fixes #36

handleCreateRun stored the raw request body as workflow_json, discarding the expanded steps from expandStrategy. With strategy: sequential, applyChain added depends_on to the expanded steps — but those were only used for DB step prepopulation, never persisted in workflow_json. The engine then read the raw body at runtime, saw no depends_on, and dispatched every step as a graph root (no chain, no ordering).

When a strategy is present, replace obj.steps with the expanded effective_steps and serialize that as workflow_json, so the chain dependencies persist for normalizeWorkflowRoot to convert into DAG edges. The idempotency-conflict check compares against the stored expanded form.

Verified: 3-step sequential workflow completes in order (a→b→c) with correct depends_on stored in the DB. Full suite green (zig build test, 355/355).

[vernonstinebaker]

Validated against #36's documented root cause: the raw body was stored verbatim, discarding applyChain's depends_on, so the engine synthesized all steps as graph roots. This stores the expanded effective_steps when strategy is present, keeps the raw-body fallback on serialize failure, and updates the idempotency payload comparison to the stored form. Scope confined to src/api.zig, CI green. Note: no unit test added — the issue's repro is DB-level (workflow_json contents); worth a follow-up test asserting the stored workflow carries depends_on after sequential strategy. Merging.