POC (do not merge): opt-in deferred data-element evaluation for #125

[ZayanKhan-12]

Draft / proof-of-concept for discussion — not intended to be merged as-is.

Follow-up to my comment on #125 (#125 (comment)). This makes that proposal concrete so it's easy to look at and react to.

Problem (#125)

Turbine resolves %data element% tokens eagerly, when a delegate module runs (createExecuteDelegateModule.js → replaceTokens(moduleSettings); also createGetExtensionSettings.js). A dynamic data element used in extension/component configuration is therefore frozen to the value it had when that module first ran — not when the action (e.g. an Analytics beacon) actually fires.

Change

A token can opt out of eager evaluation by prefixing its name with ~:

Token	Behavior
%foo%	unchanged — resolved eagerly, exactly as today
%~foo%	emitted as the still-unresolved %foo% (one ~ stripped)

The delegate module receives the literal %foo% and resolves it itself, at action-time, via turbine.replaceTokens(...). Because a second pass over %foo% resolves normally, "defer once, resolve later" composes cleanly. Adds unit tests in createReplaceTokens.test.js and a POC-issue-125.md write-up.

Verified locally against the real module:

eager single / inline ........ unchanged
%~foo% ....................... %foo%                    (deferred, unresolved)
%~foo% and %bar% ............. %foo% and <resolved bar>
%~random number% -> %random number% -> <fresh value>   (two-pass)

Why this is a draft, not a finished feature

• The ~ marker is provisional. Discuss: Data Elements' runtime evaluation cannot handle dynamic data element values #125 really asks for a component-level "evaluate at runtime" setting, which extensions don't currently have — the escape syntax (and data-element names that legitimately start with ~) needs a design decision.
• Extensions must actually call turbine.replaceTokens at action-time on the fields they want to defer; turbine can't do that on their behalf.
• The "single token returns the raw (non-string) value" contract and the token-replacement docs would need updating.

Opening as a draft purely so the mechanism is concrete for the #125 discussion — happy to change the approach, swap the marker, or close it if you'd rather keep the design in the issue. Direction is your call.