fix(LTX25-POSITION-CONTRACT): gate the tower positions as integers, and stop a note claiming a detection the same file measures as absent

[localai-bot]

tests/vllm/models/test_ltx2_text_encoder.cpp contradicted itself in one file.
The note heading the "ltx2 prompt -> conditioning: the VALUES, against the left-padded oracle" case told the reader that renumbering the tower's positions
from zero "does red this case, but only at 1.10x the audio floor". A measured
table 140 lines below it, in the same file, showed that is false post-4712dac40:
the correct code sits at 1.209x/1.313x of the propagated floor and the mutant at
0.683x/0.931x, so the comparison had INVERTED. A reader who stopped at the note
trusted a detection that does not exist.

Re-measured at this base before the note was touched, and it is worse than #1467
recorded. With positions[i] = i in src/vllm/model_executor/models/ltx2_text_encoder.cpp
the whole 27-case suite is green, 4118 of 4118 assertions. Not one case detects
the defect.

The layer-two question, asked and answered

That table says the MUTANT is measurably closer to the oracle than the port is.
The honest reading is that our position handling is wrong, and nobody had chased
it. It is not wrong, and the chase is .agents/specs/ltx25-position-contract.md.

Upstream passes no position_ids on this path. LTX-2 fd4ded7f calls the tower
with three arguments at text_encoders/gemma/encoders/base_encoder.py:64-68, and
diffusers 3a2f35d4 does the same at pipelines/ltx2/pipeline_ltx2.py:347-349.
So transformers derives them, and modeling_gemma4_unified.py:1092-1096 derives
torch.arange(inputs_embeds.shape[1]) + past_seen_tokens over the PADDED width:
the pads consume 0..P-1 and the real tokens start at P. The
attention_mask.cumsum(-1) - 1 renumbering exists only inside generate()
(generation/utils.py:713-727, sole base call site :2483), which a plain
module call never reaches. transformers 5.14.1, the parity pin, carries that
branch byte-identically. vLLM defines nothing on this path: grep -rn -i "ltx"
over vllm/model_executor/models/, over --include='*.py' for the whole
checkout at 5559679229, plus -i "lightricks" and
"LTXVideo\|ltx_video\|LTX2\|LTX-2", all return zero.

Asked of the oracle directly, against its OWN left-padded run, worst of 13 states:

dtype	|absolute - padded|	|renumbered - padded|	absolute closer at
f32	5.257e-05	1.037e-04	10 of 13
bf16	4.375e-01	1.156e+00	12 of 13, mutant 0

In f32 both are round-off on values of magnitude 14.35, which is the physics:
rotary embedding depends only on m - n and the pads are masked, so a uniform
shift cancels exactly. In bf16 renumbering is 2.64x FURTHER from upstream's own
answer and closer at none of the states. The port is right and the mutant is
worse. The end-to-end conditioning reads the other way because out.conditioning
and want_bf16 are two different bf16 realizations of one f32 trajectory, so a
perturbation of the same order as the gap between them can land on either side of
it. That is a property of the instrument, not of the port, and it is what
gen-ltx2-gemma-tower-goldens.py:363-375 already records for
partial_rotary_factor. No new issue is filed because there is no defect to file.

scripts/probe-ltx2-tower-positions.py is that measurement. It imports the
committed golden generator and calls the generator's own build_tower and
run_tower, so the fixture behind the verdict cannot drift from the fixture
behind the goldens. Identical under transformers 5.12.1 with torch 2.12.1+cpu
and under 5.14.1 with torch 2.11.0+cu130.

What changes

Ltx2PromptConditioning carries the positions vector the tower actually ran
on, bound by reference rather than copied beside it, and the case REQUIREs it
against the golden's own pad count. That is an integer contract, upstream of
every rounding that could absorb it. The stale note becomes what the table below
it measures and points at the new assertion.

No tolerance is widened and none is moved. The four <= 2.0 * floor value
assertions are byte-identical to base and the measured table is kept intact. A
constant could not recover this detection anyway, because the ordering of correct
and mutant has reversed, and reaching for one is what #1668 forbids.

Evidence

One build directory, CPU-only Release (-DVLLM_CPP_CUDA=OFF, NDEBUG), Ninja,
x86_64, gcc 13. Compile rc 0 on every arm. ltx2_text_encoder.cpp pristine
sha256 8911296882e03ea072a3d6b1898b7fff88503c2f048683802a2a7a43de07a59c,
restored and re-verified.

tree	result	this case's ratios
base, unmutated	SUCCESS 27/27, 4118 of 4118	video 1.20939x, audio 1.31288x
positions[i] = i	SUCCESS 27/27, 4118 of 4118	video 0.683056x, audio 0.93133x
that mutation + the new REQUIRE	FAILURE, 8 of 4127 failed	RED at test_ltx2_text_encoder.cpp:2398, all T=8 positions
pristine + the new REQUIRE	SUCCESS 27/27, 4127 of 4127	unchanged

The full build is rc=0 with zero errors across all 1141 targets, and
ctest -R ltx2 is 12 of 12 passed.

test_cpu_x86_llamacpp_floor is FLAKY on this box under load. It failed three
times during this work, always on
CpuX86FloorHarnessTests.test_a_contended_leg_is_discarded_and_never_summarised
with NO_QUIET_WINDOW at loads between 40 and 170 from other sessions, and it
passed 10 of 10 standalone in 19.4 s in the one window that was quiet. This row
changes no CPU kernel and no harness -- the diff touches nothing under
tests/scripts/ or src/vt/. It is neither caused nor repaired here. The final
scripts/agent-preflight.sh on the merged head reports All gates green.

Fresh review

Reviewed at fc357094f by an agent that did not write it, in its own detached
worktree, tree restored and sha256sum-verified after each mutation. Verdict
FINDINGS, none blocking. It reproduced every cell of the oracle table on both
transformers stacks, verified all fifteen upstream and in-repo anchors, and
confirmed that zero non-comment test lines were removed and that the four
2.0 * floor assertions are byte-identical to base.

Its four notes are repaired in 522097f01:

• The reference binding on out.positions is the whole contract and nothing
  gates it -- the review mutated it (copy instead of &, tower fed a renumbered
  vector) and the suite stayed green at 27/27. The comment now says so.
• ## Design item 4 was headed "Reachability" and delivered something narrower:
  deleting the ltx2_video.cpp:2278 call site does NOT red this case, because
  the case enters one level below Ltx2VideoEngine::Generate. That entry point
  is pre-existing and this row adds assertions to it rather than a capability.
  Recorded plainly so M1 is not mistaken for a reachability proof.
• The evidence table labelled its first two rows "HEAD" when their counts and
  the recorded pristine sha belong to the base tree. Relabelled.
• scripts/probe-ltx2-tower-positions.py is run by no gate and cannot be, since
  CI has neither torch nor a transformers that registers gemma4_unified.
  Named as owed rather than assumed durable.

The fifth note was that the branch had fallen behind main. Merged
VT-CONV1D-BLOCK-CONDITION (#1770) and re-gated on the merged head: the focused
suite is SUCCESS at 27/27 and 4127 of 4127, and the positions[i] = i
mutation still reds it at exactly 8 of 4127, restored byte-for-byte after.

Closes #1467.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]