varip UDT initializer reads the default when it depends on an earlier declaration #258

Found while fixing #226. #226 covers the var form; the varip form of the same script has the same defect and is not changed by that fix.

Minimal script

//@version=6
strategy('varip gap', initial_capital = 100000)
type State
    float value
float base = strategy.initial_capital / 100
varip state = State.new(value=base)
observed = state.value

Expected: observed equals strategy.initial_capital / 100 (1000 with initial_capital = 100000 as in the script above), as it does for var state = State.new(value=base) after the #226 fix, and as it does when the dependency is written inline: varip state = State.new(value=strategy.initial_capital / 100).

Actual: observed is 0. The varip initializer is emitted in the first-bar preamble, before the statement that assigns base, so the constructor reads the zero default of base. Run on the generated C++ with eight flat bars: var before #226 gives 0, after it 1000; varip gives 0 before and after; the inline controls of both give 1000.

Scope: shown by a run only for the UDT script above. By reading the emission (not run), the other aggregate initializers (array, map, matrix, UDT built by a helper) declared varip with a dependency on a value that only the statement walk computes take the same route and should read the default the same way.

Constraint for the fix: varip storage and its first-run latch stay outside the calc_on_order_fills rollback checkpoint (a varip value set on the first bar survives a recalculation, and its initializer runs once). A declaration-site once-flag, as #226 uses for var, would be a new latch and must join that inventory. A fix needs a rollback test for a dependent varip aggregate next to the existing varip calc_on_order_fills tests.

Not a regression: this behavior predates #226; the report only records that the var fix does not cover it.