#2915 model cancel --all on a running workflow leaves its method-run records at running, or records them failed instead of cancelled

Description

When swamp model cancel --all stops the process that owns a running workflow, the per-step method-run output records are not settled as cancelled. Reproduced on 20261001.174510.0-sha.265caa01 while triaging swamp-club#2910.

The workflow owner exits with code 1 about 0.6 s after SIGTERM. It does not wait out the shell step executor's 3 s SIGTERM-to-SIGKILL grace (KILL_GRACE_MS in src/infrastructure/process/process_executor.ts), so method runs whose steps are still stopping never get their final output saved.

• Steps that are slow to stop on SIGTERM: both method-run records stay at status running indefinitely, with no completedAt. The tracker rows and the workflow run show cancelled.
• Steps that exit promptly on SIGTERM: both method-run records and tracker rows show failed, not cancelled. The workflow run shows cancelled with cancel_reason The signal has been aborted.

swamp-club#2897 made workflow cancel wait for the owner and settle the workflow run record. It does not settle the per-step method-run output records, and model cancel does not use that path.

Steps to reproduce

1. Two command/shell models whose execute method runs a script that traps TERM, writes to a file, sleeps 5 and exits: trap 'echo got >> trap.txt; sleep 5; exit 0' TERM; sleep 60 & wait
2. A workflow with one step per model and no dependsOn, so both run in parallel.
3. swamp workflow run in one shell.
4. After a few seconds, from a second shell: swamp model cancel --all
5. swamp model method history search --json

Repeat with a plain sleep 60 method to see the failed variant.

Expected

The owner waits for its in-flight steps to stop, and each method-run record ends as cancelled with the cancel reason.

Actual

The owner exits 1 at about 0.6 s. Records are left at running (slow steps) or recorded as failed (prompt steps).