ltm: the ceteris-paribus wrap leaves a LOOKUP table argument's runtime index live in every link-score partial

[bpowers]

Problem

wrap_non_matching_in_previous (src/simlin-engine/src/ltm_augment.rs, the LOOKUP / LOOKUP_FORWARD / LOOKUP_BACKWARD arm around line 685) holds the TABLE argument (child 0) verbatim and only wraps the index argument(s).

Holding the table reference verbatim is correct and deliberate: a graphical-function table is static data with no value slot, so lookup(PREVIOUS(table), ...) cannot compile, and wrapping it silently zeroes the whole link-score fragment. That is the failure mode behind WRLD3's identically-zero table-mediated link scores, and the in-code comment says so.

The defect is that the arm holds the whole argument verbatim, including any subscript index expressions inside it -- and those are genuine runtime value reads:

LOOKUP(g[idx], x)                  -- `idx` is a variable read
LOOKUP(pop[Region, other], x)      -- likewise

compiler::codegen::extract_table_info (src/simlin-engine/src/compiler/codegen.rs:610) evaluates such an index to select the table element at runtime: its Expr::Subscript arm computes an element offset from the index expressions (offset = sum(index_i * stride_i), built out of the live index Exprs), while its Expr::Var / Expr::StaticSubscript arms resolve a static one to a constant.

So for a target whose equation contains LOOKUP(g[idx], x), every link-score partial of that target varies with the current-step value of idx, even though ceteris paribus requires everything except the live source occurrence to be frozen. The score misattributes idx's influence to whatever source is being isolated.

Scope

This affects all link-score partials, not just the PerElement ones. For the non-PerElement callers the wrap's ctx.pin is None, so the table argument is returned completely untouched (the None => a branch) -- no pin descent, no freeze, nothing.

It predates branch roundtrips-track-a2.

How it was found

A codex review pass on roundtrips-track-a2 flagged the same defect in the narrow PerElement path, where that branch had just made the fragment reach compilability. Commit fb0863b0 ("engine: gate the LTM table-index refusal on the enclosing freeze") fixes only the PerElement path: it declines a bare table argument carrying a runtime index (pin_dimension_name_indices returns discharged = false, which becomes WrapOutcome::missing_occurrence, i.e. a warned skip) while keeping one that is already inside a freeze (a pre-existing PREVIOUS / INIT, a whole-frozen reducer), since a freeze lags the index read too.

The general case outside that path is untouched -- hence this issue.

Why it matters

Correctness of link scores, and silently so: the partial simply reports a wrong number. There is no compile failure and no diagnostic; the score just attributes the table index's per-step movement to the isolated source. This is the "degraded score masquerades as a real one" hazard class (#546 / #548 / #587 / #759).

Components affected

• src/simlin-engine/src/ltm_augment.rs -- wrap_non_matching_in_previous (the LOOKUP arm), wrap_index_non_matching_in_previous, qualify_element_index
• src/simlin-engine/src/compiler/codegen.rs -- extract_table_info (why the index is a runtime read)
• src/simlin-engine/src/db/ltm_char_golden/ -- 16 char goldens that may need regeneration

Suggested fix direction

Give the wrap's own index pass (wrap_index_non_matching_in_previous) the table argument's index expressions, instead of holding the entire argument verbatim. That keeps the table head static (still no PREVIOUS around the table itself) while freezing the index reads like any other other-dep.

Two things a fix must handle:

1. The index pass already carries the element / dimension-name guards (qualify_element_index, the element-of-any-dimension and dimension-name arms), so a static element selector must stay static -- reuse those guards rather than reimplementing them.
2. The change could alter generated equation text, so the 16 char goldens in src/simlin-engine/src/db/ltm_char_golden/ should be checked. None currently contains a LOOKUP inside a partial, so it may well be a no-op for them.

Note on the deliberate decision

"Hold the table argument verbatim" is a deliberate decision with a real motivation (it fixed WRLD3's identically-zero table-mediated link scores). It should therefore be revisited on its own terms -- with a test that pins both halves (the table head stays unwrapped AND the index gets frozen) -- rather than changed as a side effect of some other refactor.

Related: #983 (sibling LTM finding filed from the same branch). Mechanically adjacent but distinct from #759, which is the opposite error (over-wrapping a dimension name inside a subscript index); this one is under-wrapping a genuine runtime index because it never reaches the index pass at all.

[bpowers]

Still open after the table-index freeze: the index resolution underneath it is project-wide

The wrap now freezes a LOOKUP table argument's subscript index (freeze_lookup_table_indices,
landed on the round-trips burndown branch), which fixes the shape this issue's title describes. It
does not close the issue, because the freeze only fires for an index the wrap classifies as a
runtime read, and that classification is still made by two project-wide predicates. This comment
records the reproduction and the structural reason, so the next attempt starts here.

Two corrections to the record while I am here:

• The claim that this is "not reachable today" because the target's own fragment fails with
  DoesNotExist first is wrong, not merely conservative. It is true only for an index that
  appears nowhere else in the equation. Adding any second reference — + 0*idx is enough — buys
  the index into classify_dependencies' scope and the whole thing compiles.
• The fix therefore needs a real LOOKUP fixture to be tested at all. An ordinary subscripted
  arrayed variable (q[idx]) takes a different code path and does not exercise this one.

Reproduction: compiles with zero diagnostics, score moves by 1.0

{UTF-8}
D: A1, A2 ~~|
B: idx, spare ~~|            <-- declared, referenced by NO equation
g[A1]( (0,0),(1,10),(2,20) ) ~~|
g[A2]( (0,0),(1,100),(2,200) ) ~~|
idx = 1 + MODULO(Time, 2) ~~|
inflow = 1 ~~|  src = INTEG(inflow, 1) ~~|
y = g[idx](src) + 0*idx ~~|

	diagnostics	emitted src→y partial	simulated link score
B not declared	0	lookup(g[PREVIOUS(idx, idx)], src)	[0, 0.05263, 0, 0]
B declared	0	lookup(g[idx], src)	[0, 1.0, -1.0, 1.0]

idx is a genuine runtime value. Declaring a dimension that no equation references leaves it live
inside a partial that is supposed to be ceteris-paribus, with no diagnostic in either model. The
same shape reproduces on the PerElement emitter, where the failure is one step worse — the index is
rewritten to bucket·ctr, an element of a dimension the indexed variable is not declared over, which
compiles and statically reads slot 1 forever:

Region=[nyc,boston]  Age=[young,old]  Slot=[s1,s2]  [Bucket=[ctr,spare]]
ctr = 1 + (INT(counter) MOD 2)
q[Slot]: s1 = 1*drive, s2 = 10*drive
growth[Region] = pop[Region, young] * 0.1 + q[ctr] * 0.002 + 0 * ctr

	pop[nyc,young]→growth[nyc] partial	simulated score
Bucket not declared	PREVIOUS(q[PREVIOUS(ctr, ctr)])	[0, .7246, .98795, .94652, .99394, .96721]
Bucket declared	PREVIOUS(q[bucket·ctr])	[0, .7246, .98795, **.80214**, .99394, **.81967**]

Same diagnostic count both ways.

Why the GH #986 unification does not reach here

dimensions::resolve_axis_index_name is the engine's single element-vs-dimension precedence rule and
is what compiler::subscript::normalize_subscripts3 implements. GH #986 unified
ltm_agg::classify_axis_access and ltm_augment_post_transform::pin_dimension_name_indices onto it;
the wrap was the third consumer and has now been partially unified too
(ltm_augment::index_axis_verdict). Partially, because resolving an index needs the axis — the
declared Dimension at that index's position of the subscripted variable — and the wrap gets it from
IteratedDimCtx::dep_dims.

A graphical-function table holder can never be in dep_dims. That table is built from
variable::classify_dependencies(..).all, and the BuiltinContents::LookupTable arm records the
holder in referenced_tables and deliberately keeps it off the dependency graph (GH #606 — a
lookup-only holder is a static table, not a value-bearing variable, and a bare Var reference to one
is a compile error, so there is no other route into all either). So axis_dim_at always returns
None on this path, axis_unknown is always true, and the two project-wide predicates
(dimension_uniquely_containing_element, is_element_of_any_dimension) still decide every table
index. Nothing in the test suite constrains it: deleting the call site outright leaves 5,435 tests
green, which is why it is now a literal None with a comment rather than a call that reads as
coverage.

generate_per_element_link_equation reaches the same fallbacks for a different reason — it threads
dep_dims: None, on a comment that was true when other_dep_verdict was that table's only consumer.

What closing this needs

The wrap needs the subscripted variable's declared dimensions from the source of truth the compiler
uses (db::variable_dimensions, or the project's DimensionsContext), not from a table of the
target's array dependencies. Those are different questions and the mismatch is exactly what bounds
the current fix: "absent from dep_dims" is being read as "no axis exists", when it also means "this
emitter did not thread the table" and "this kind of reference is not a dependency by construction".

That is a decision about where this function family gets its dimension truth — it deliberately
carries none today, which qualify_element_index's rustdoc has said honestly for a long time — so it
is its own change rather than a rider. Both fixtures above are ready to become its tests; the second
one is four lines on top of the existing arrayed_gf_lookup_mdl fixture in
src/simlin-engine/src/db/ltm_char_tests.rs.

Related: the partial above is not fully ceteris-paribus even once every name resolves, because an
index frozen inside an already-frozen head is double-lagged (reads the head at t-1 indexed at
t-2, where the PREVIOUS(target) anchor indexed at t-1). That is a separate semantics question
and is disclosed on the burndown PR.