Workflow execution repeats #1091: cross-model CEL expression validation fails for unresolved types

[keeb]

Description

The workflow execution path in execution_service.ts has the same bug that #1091 fixed for validateSingle() — it only resolves the target step's model type before validation, but cross-model CEL expressions reference types that haven't been resolved yet.

#1092 fixed this for validateSingle() in src/libswamp/models/validate.ts by resolving all model types before validation. The workflow execution path at src/domain/workflows/execution_service.ts:254-264 was not updated.

Steps to Reproduce

1. Model dedup (@keeb/mms/dedup) has globalArgs with CEL: ${{ model.llm.definition.globalArguments.ollamaUrl }}
2. Model llm is type @keeb/ollama (different extension type)
3. swamp model validate dedup → passes (fixed by fix: resolve all model types before single-model validation #1092)
4. swamp model method run dedup filter → passes (resolves types on demand)
5. swamp workflow run discover-and-download → fails: Unknown model type "@keeb/ollama" for model "llm"

Root Cause

execution_service.ts line 254 calls resolveModelType(modelType, ...) for the step's model only. Line 260 then calls validateModel() which evaluates CEL expressions referencing other models. Those models' types are not in the registry.

Fix

Apply the same pattern as #1092: resolve all model types in the repo before running per-step validation. Or resolve types on-demand during expression evaluation.

Affected Code

• src/domain/workflows/execution_service.ts lines 253-264
• PR fix: resolve all model types before single-model validation #1092 fixed the equivalent path in src/libswamp/models/validate.ts

[keeb]

The deeper issue is that model validation is implemented in two separate code paths that need to converge:

1. CLI path: src/libswamp/models/validate.ts — used by swamp model validate and swamp model method run
2. Workflow path: src/domain/workflows/execution_service.ts:260 — used by swamp workflow run

Both call validateModel() but set up the type registry differently. Fixing one doesn't fix the other (#1092 proved this). These should share a single pre-validation setup that resolves all model types, rather than each entry point doing it independently.