#1782 manual_approval suspends the run while parallel sibling jobs are mid-flight; in-flight steps are torn down and left `running`

Summary

When a manual_approval step is reached, the process exits immediately even if other jobs at the same dependency level are still executing. The in-flight model method is torn down ([WRN] model·method·run·cleaner·execute: Failed to run reports for failed method: "Cannot push to a closed AsyncQueue"), the run tracker records that method run as failed, but the workflow run record keeps the step at status: running. swamp workflow resume later re-executes the step (double side effects for non-idempotent work).

Steps to reproduce

jobs:
  - name: deploy
    steps: [ … any quick step … ]
  - name: gate
    dependsOn: [{ job: deploy, condition: { type: succeeded } }]
    steps:
      - name: production-gate
        task: { type: manual_approval, prompt: "Approve?", timeout: 3600 }
  - name: cleanup
    dependsOn: [{ job: deploy, condition: { type: completed } }]
    steps:
      - name: gc
        task:
          type: model_method
          modelType: command/shell
          modelName: cleaner
          methodName: execute
          inputs: { run: echo cleanup done }

swamp workflow run wf → cleanup │ start, gate │ waiting approval…, the AsyncQueue warning, Suspended workflow. swamp workflow history get wf --json shows cleanup.gc: running; swamp run history shows the method run failed. Reproduces every time.

Expected

Either (a) suspension waits for in-flight sibling steps to reach a terminal state before persisting the suspended record, or (b) siblings are cancelled cooperatively and recorded as cancelled, never left running. The manual ("Understanding Workflow Suspension") describes the record as a consistent checkpoint.

Environment

swamp 20260822.011157.0-sha.06b61472, Linux x86_64.