#2597 workflow resume cleanup mode can run an always-gated teardown before a suspended job's approved work

Summary

With swamp-club#2550, a job a resumed run was suspended in counts as unfinished work: when the resume's cancellation fires, later job levels run in cleanup mode, but the job itself is failed only if this resume started it. A job the cancellation kept from starting (for example, a resume aborted before its first level, where the suspended job shares its level with other jobs) stays running with its approved steps still pending.

TriggerCondition.always() is true whatever the dependency's status, so a teardown job that depends on that suspended job with an always condition runs to success in cleanup mode while the suspended job's approved work (the steps after its gate) never ran. The run then ends cancelled, and a cancelled run cannot be resumed, so the approved work never runs at all. For a teardown-style job this inverts the intended order: teardown runs, the work it tears down never happened, and the record shows teardown succeeded after a job that is still running.

Steps to reproduce

1. A workflow with jobs main (a manual_approval gate, then a step post that depends on the gate succeeding), side (any step, no dependencies, so it shares main's level), and teardown (dependsOn main with condition always).
2. swamp workflow run, then approve the gate.
3. Resume with a signal that is already aborted (for example a very short --timeout that fires before the first level starts).

Observed (after swamp-club#2550): main stays running with post pending; teardown runs and succeeds; the run ends cancelled.

Expected (to decide)

One option, suggested by the adversarial review on the swamp-club#2550 PR: when evaluating always/completed conditions in cleanup mode, treat a dependency that is still running and was not started by this walk as not yet satisfied, so teardown does not run ahead of work that never ran. The alternative, not entering cleanup mode for inherited running jobs at all, brings back the swamp-club#2550 symptom (always-gated cleanup started with the aborted signal and killed at once), so a condition-level fix looks preferable.

Where

src/domain/workflows/execution_service.ts: finishJobLevel (the anyJobFailed derivation counts running jobs), enterJobLevel (fails only jobs in startedJobs), and shouldJobRun / TriggerCondition evaluation. Covered today by the test named: resume cleanup: a resume aborted before it starts leaves the approved gate's job running, and still runs cleanup.

Context

Found by the verify-reviews adversarial review of the swamp-club#2550 fix.