#4184 A step settled after the abort overwrites the expression-context entry of a same-named step that ran in another job

Found by code review while fixing #4175. Traced in the code, not reproduced.

The step-level settlement #4149 added (settleLevelStep in runJob, src/domain/workflows/execution_service.ts) writes the status of a settled step with outputs undefined to expressionContext.steps. That map is keyed by step name alone and shared across a run's jobs, so a settled step replaces the entry of a step with the same name that really ran in another job. A later cleanup step then reads the wrong status and loses that step's outputs, which it may need to tear down what the run created.

#4175 fixes the same overwrite in the job-level settlement by keeping an existing entry (??=). The step-level site was left as it is to keep that change scoped. The fix is expected to be the same, with a test where a settled step and a step that ran in an earlier job share a name.