#1785 Cancellation/--timeout skips remaining steps including `completed`/`always` branches; --timeout waits for the in-flight subprocess

Summary

1. swamp workflow run wf --timeout 3 on a step running sleep 20 returns after ~21 s, not 3 s: the timeout is cooperative and the command/shell subprocess is not signalled. The step is recorded failed (not cancelled), the run cancelled.
2. After cancellation (timeout, Ctrl-C, or swamp workflow cancel) every remaining step is skipped — including steps whose dependency condition is completed or always. Cleanup/notification branches therefore never run on cancel, which is the case where operators most need them.

Steps to reproduce

jobs:
  - name: main
    steps:
      - name: sleepy
        task: { type: model_method, modelType: command/shell, modelName: sleeper, methodName: execute,
                inputs: { run: "echo start; sleep 20; echo end" } }
      - name: on-cancel
        dependsOn: [{ step: sleepy, condition: { type: completed } }]
        task: { type: model_method, modelType: command/shell, modelName: notifier, methodName: execute,
                inputs: { run: echo after-cancel } }

time swamp workflow run wf --timeout 3 → 20.9 s wall clock; history: sleepy: failed, on-cancel: pending, run cancelled.

Expected

• --timeout signals the in-flight subprocess (SIGTERM then SIGKILL after a grace period) and marks the step cancelled.
• always (and arguably completed) dependents still run after cancellation so cleanup can happen, or the reference documents explicitly that cancellation skips all branches and recommends a pattern.

Environment

swamp 20260822.011157.0-sha.06b61472, Linux x86_64.