#2433 workflow resume --from: a step moved or renamed since the run failed is skipped and the run reported succeeded, or crashes with 'Step run not found'

Problem

swamp workflow resume <wf> --from <step> --run <id> uses the current workflow YAML. If the step was moved to another job or renamed since the run failed, --from does not detect it. Depending on the edit, the run is reported succeeded without running the step, or the resume crashes and leaves the run in an inconsistent state.

Moved to another job, nothing in the new job depends on it: false success. The workflow has job build (compile → test) and job release (publish), where release depends on build. test fails. Move test into release and run resume --from test:

build │ completed
system │ Completed workflow moved succeeded

The command exits 0 and no step runs. The run record says succeeded, with build.test: pending, release: skipped, and release.publish: skipped. In the repro, test would have failed again if it had run. A caller that checks the exit code or the run status sees a success that never happened.

Moved to another job, a step in the new job depends on it: crash. The same move, with publish depending on test in release: resume --from test fails with [FTL] error: Error: Step run not found: test and exits 1. The run is failed, but job build is succeeded with test: pending, and job release is stuck at running with publish: pending.

Renamed: crash. Rename the failed step b to b2 and run resume --from b2: Step run not found: b2, exit 1. The run stays failed with the dependents of b left pending. On the swamp-club#2409 branch, a later resume --run <id> then refuses because those steps are pending.

A removed step is handled: --from a step that is still in the run re-runs that step and its dependents, and the run completes.

Reproduced on main at c811f8ce and on the swamp-club#2409 branch, which does not change the --from code.

Cause

computeStepsToReset (src/domain/workflows/execution_service.ts) checks the --from step only against the current workflow. It then maps each template in the reset set to stored step records by name across all jobs, without checking that the record is in the job where the current workflow puts that step. Execution walks the current workflow's jobs and looks up each step's record in that job's stored run:

• A step with no record in that job throws Step run not found.
• A record left in a job the workflow no longer puts the step in is never executed, so it stays pending.

The job and the run are then completed as succeeded even though a step is still pending.

The failed-run retry added by swamp-club#2409 refuses these shapes before changing anything (selectRetryTemplates: each entry template must be a step of the same job in the current workflow) and suggests starting a new run. --from has no equivalent check.

Fix approach

• Before the first change, check that every template in the --from reset set has a stored record in the job where the current workflow places it. If not, refuse with a UserError that names the step and says to start a new run. Because the check runs before any mutation, the run stays failed and unchanged.
• As a backstop, do not complete a job or a run as succeeded while any of its steps is still pending.

Reproduction (false success)

1. Create workflow moved: job build with compile, then test (depends on compile, runs a command that exits 1); job release (depends on build) with publish.
2. swamp workflow run moved: test fails. Note the run id.
3. Edit the YAML: remove test from build and add it to release as an independent step next to publish.
4. swamp workflow resume moved --from test --run <id>: exits 0, Completed workflow moved succeeded, no step runs.
5. swamp workflow history get moved --json: status: succeeded, build.test: pending, release: skipped.

For the crash, give publish a dependsOn on test in step 3.

Related: swamp-club#2432 (the Step run not found crash prints as a fatal error with a stack trace).