#2496 Direct-execution workflow steps validate evaluated globalArgs, so the CEL concatenation workaround for colliding template names fails

What happens

Some workflow steps run a model type directly, with the global arguments written inline in the step (task.modelType, task.modelName and task.globalArgs). There, the workflow evaluator substitutes those values before the step executor synthesizes the definition and runs validateModel on it (execution_service.ts, around line 914). The validation scan therefore sees evaluated values, not what the author wrote.

The CEL concatenation workaround from #2424 does not survive this. globalArgs: { message: '${{ "{" + "{env.name}" + "}" }}' } reaches validation as {{env.name}}. That is classified as a dropped dollar on the swamp root env, so the step fails with Model validation failed. The error then suggests the very concatenation the author already used. The synthesized definition is saved with the evaluated text, so a later swamp model validate on it fails too.

Only colliding roots are affected. Foreign text such as {{host.name}} only warns, and before #2424 every bare {{ failed on this path.

Expected

Validation of a direct-execution definition should look at the author-written step globalArgs, not the substituted values. Alternatively, it should not re-flag text that evaluation produced. If neither is feasible, the error on this path should offer only the remedies that work here: declaring the field, or using a named definition.

Found by the adversarial review of #2424. The workaround and its limitation are documented in design/enablers/expressions.md.