Property panel: accept $var loop-variable references for operators inside a control block

[aglinxinyuan]

Feature Summary

The property panel has no notion of control blocks or loop variables. A user who wants an operator inside a LoopStart/LoopEnd block to use the loop's variable K has no way to say so: a numeric field rejects anything but a number, nothing tells her which variables the enclosing block declares, and the workflow compile request would carry whatever she typed as a plain literal.

Proposed Solution or Design

For an operator that lies inside a block (reachable from a LoopStart and reaching a LoopEnd):

1. Accept $name references in property fields of any primitive type (string, integer, number, boolean). The field keeps the text $K; the JSON-schema validation treats a value matching ^\$[A-Za-z_]\w*$ as valid for that field, and the value is sent unchanged in operatorProperties (the backend records and binds it; see Let operators inside a control block read loop variables through $var property references #8635).
2. Autocomplete the reference from the variables the enclosing LoopStart operators declare in their initialization code field (top-level assignments such as K = 2; prev = ...), and flag a $name that no enclosing block declares.
3. Block membership as a reusable utility on the workflow graph (an operator's enclosing LoopStart operators), so the panel, validation and later features share one definition.

Operators outside any block keep today's behavior.

Acceptance

• Unit tests (Vitest) for block membership on straight, branching and nested graphs, for initialization-variable extraction, and for the $name validator.
• Typing $K into a numeric field of an operator inside a block is accepted and sent as "$K"; the same in an operator outside a block is rejected as before.

Affected Area

Workflow UI