#4179 A lone step in a job still starts under the aborted signal when another job has suspended the run

Found by adversarial review of #4149. Traced through the code, not reproduced.

The rule #4149 adds for a step level reached after the abort is turned off when run.status is suspended (runJobInSpan in src/domain/workflows/execution_service.ts), so that a suspended run keeps its pending steps to resume. merge() starts a single stream whatever the signal, so that only keeps steps pending in a level of two or more.

Traced scenario: parallel jobs A and B are running and A suspends at an approval gate, which sets run.status to suspended. The abort fires while B is still running, and the next level of B holds one pending step. That step starts under the aborted signal, or launches a nested child, and most likely fails through failInFlightStep. That failure is not marked settledByAbort, so reopenAbortedWork does not reopen it after approval. A two-step level in the same position stays pending and does resume.

Expected: when the run is suspended and the signal has aborted, a level leaves its pending steps unstarted, in a level of any size, so the resume runs them.

Suggested fix: filter out the streams of the level's pending steps in that case. Note the design text added by #4149 says such a level starts no work whether or not its steps share the level, without mentioning this exception.