fix(api): persist strategy-expanded steps as the run workflow

[raskevichai]

Closes #36.

Root cause

handleCreateRun expands the strategy into effective_steps, then stores the raw request body as workflow_json:

ctx.store.insertRun(run_id, idempotency_key, "running", body, input_json, callbacks_json)

The expanded array was used only to prepopulate the steps table. Since the engine rebuilds its graph from workflow_json at tick time (engine.zig:416), it read steps with no depends_on, treated all of them as graph roots, and dispatched them concurrently.

So applyChain was deriving the edges correctly the whole time - they were just never written down. That also explains #34 (sequential not enforcing chain order): same root cause, observed from the scheduling side.

Changes

1. Store the expanded workflow. New buildExpandedWorkflowJson copies the top-level fields, swaps in effective_steps, and drops strategy and reduce - expansion has already consumed those into depends_on edges and a synthetic reduce step. Leaving them in would let a later reader re-derive a graph that disagrees with the steps stored beside it.

2. Idempotency comparisons moved to the same representation. This part is not in the issue but the fix is wrong without it.

workflow_json is compared against the incoming payload in two places (the early replay check, and the post-insert race path). With the expanded form stored and the raw body compared, an ordinary retry of a strategy run compares expanded-vs-raw, mismatches, and returns 409 conflict instead of a 200 replay. Expansion is therefore computed before the idempotency check so both sides use one representation.

3. No-strategy path unchanged. When there is no strategy, the body is still stored verbatim. Runs written before this change stay byte-comparable, so existing idempotency keys keep replaying correctly.

Tests

Four regression tests:

• sequential strategy stores expanded depends_on in workflow_json - the stored workflow has depends_on and no longer has strategy.
• workflow without strategy is stored verbatim - guards the backward-compatibility path above.
• strategy run replays instead of conflicting on identical body - guards the idempotency interaction; without change 2 this returns 409.
• strategy run still conflicts on a different body - conflict detection still works.

Sanity check: restoring the original insertRun(..., body, ...) line makes tests 1 and 3 fail, and restoring the fix produces a byte-identical tree.

Verification

zig fmt --check src/api.zig    # clean
zig build test --summary all   # 359/359 passed  (355 before, +4 from this PR)

Scope

Not included, though they touch neighbouring code:

• BUG: parallel strategy reduce block fails with 'unknown step type' #33 (parallel + reduce rejected as "unknown step type") is a separate defect: strategy.zig emits type: "reduce" but StepType has no such variant. It needs either a new enum variant or a different synthetic type, which is a schema decision worth its own PR.
• BUG: engine executes ready nodes sequentially — parallel dispatch broken (P1) #37 (engine executes ready nodes sequentially) is in engine.zig's dispatch loop and is unaffected by where the workflow is stored.

I have not run the e2e suite (tests/test_e2e.sh) since it needs Python mock workers and a live server; the change is covered at the API layer instead.