#3190 stagecraft: let a method or workflow stage's target use {{name}} placeholders from run data

Problem

A method stage's target is fixed. work.method.modelIdOrName (and a workflow stage's name under work.workflow) is copied into the dispatch packet verbatim (engine/dispatch.ts), so a definition cannot choose which model or workflow to call from run data.

software-factory allowed this by evaluating ${{ }} in every string, modelIdOrName included, e.g. modelIdOrName: "agent-${{ self.workItem }}". stagecraft rejects ${{ anywhere (see DESIGN.md, "Why software-factory's ${{ }} could not be kept") and fills {{name}} placeholders only in systemPrompt and command. A definition that targets a model per work item has no stagecraft form. #3141 hit this porting a software-factory definition, and a migration to stagecraft hits it too.

Why not placeholders filled from bindings, as first asked

In a workflow or method stage every binding was also sent to the call as an input. A binding used only to name the target would have been sent as --input <name>=..., and swamp refuses a model-method input the method does not declare (Unknown method input(s): ..., for built-in and extension types alike; a workflow with a closed inputs schema refuses it too). So named values and what a call sends are split.

Request (as shipped)

Definition schemaVersion 2:

• work.bindings becomes work.let: named bare CEL values, the only place CEL goes.
• A workflow or method call sends the let values its passAsInputs lists, under their own names and with their types kept, beside its literal inputs. A let value not listed is never sent.
• {{name}} fills text fields from let values: systemPrompt, command, and now workflow.name and method.modelIdOrName. validate checks every placeholder and every passAsInputs name against let.
• A filled target: every value must be a non-empty string, and the result must be a name swamp would create (swamp's model-name or workflow-name rule, mirrored in _lib/engine/swamp_names.ts). Otherwise the dispatch fails and records nothing. A literal target is left as written (it may name an older model); validate warns when it breaks swamp's rule.
• The filled target is in the dispatch packet and recorded on the dispatch. The studio's design view shows the template.
• A v1 definition is upgraded on read (#3194): its bindings become let, and its call's passAsInputs names every binding, so it sends exactly what it sent before. Work items in progress keep running; swamp rewrites factory files on validate.

Done

A definition can write modelIdOrName: "agent-{{item}}" with item under work.let, validate checks it, the dispatch packet and the dispatch record carry the filled name, a null value or one swamp would not accept as a name fails the dispatch, and a v1 definition with bindings keeps working unchanged.