Workbench var-strip rebuild signature ignores enum option identities (only counts them)

renderVarStrip's rebuild-signature computation (src/ui/workbench/variable-strip.ts, the sigNew build — moved verbatim from src/ui/app.ts, present unchanged on origin/main before the #588 phase-4 refactor) folds in each variable's control kind and enumOptions.length, but not the option identities:

return v.name + ':' + v.type + (v.optional ? '?' : '') + (v.conflict ? '!' : '')
  + ':' + c.kind + (c.enumOptions ? c.enumOptions.length : '');

Repro: a variable's inferred enum options change from ['a', 'b'] to ['c', 'd'] (same cardinality) between two renderVarStrip passes — e.g. a background schema/column reload landing between keystrokes. The signature is unchanged, so the strip does not rebuild, and the dropdown keeps offering the stale ['a', 'b'] set even though deps.params.inferredEnumOptions(...) now returns different values.

Surfaced during phase 4 of the #593 refactor umbrella's PR review (#604) — pre-existing, not introduced by that PR, and deliberately left unfixed there (a pure structural extraction is not the place for a behavior change). A comment at the signature site documents this; no regression test was added for the same reason.

Suggested fix direction: fold a stable digest of the option identities themselves into the signature (e.g. join the resolved enumOptions array), not just its length.

Start in src/ui/workbench/variable-strip.ts at renderVarStrip and its sigNew rebuild-signature computation, comparing it with the moved code from src/ui/app.ts. Reproduce two passes where inferred enum options have the same length but different identities, then add coverage showing the dropdown updates from the old set to the new set. Done means option identity changes trigger a rebuild without relying only on enumOptions.length.