The ltx2 prompt->conditioning case no longer detects position renumbering: post-`4712dac40` the mutant is CLOSER to the oracle than the correct code, so the instrument is inverted

[localai-bot]

Found while gating #1458 (PR #1461), and measured rather than inferred. Filed in
flow; #1461 does not repair it because no constant on that quantity can.

What was lost, and by what

tests/vllm/models/test_ltx2_text_encoder.cpp, the case
"ltx2 prompt -> conditioning: the VALUES, against the left-padded oracle",
carries a note that renumbering the tower's positions from zero
(positions[i] = i at src/vllm/model_executor/models/ltx2_text_encoder.cpp:1090-1091,
instead of first_valid + i) reds it "at 1.10x the audio floor".

That was true, and it is not true any more. Measured on this fixture in one build
directory, CPU-only Release (so NDEBUG), x86_64, compile exit code 0 on every arm
and every source restored sha256sum-verified — ratios are to the propagated
floor, and the audio arm is the one that carried the detection:

src/vt/cpu/cpu_ops.cpp	production code	video	audio	verdict at the OLD 1.0x bound
before 4712dac40	correct	0.565	0.688	pass
before 4712dac40	renumbered	0.831	1.099	RED — the documented 1.10x
at aeba0de6f	correct	1.209	1.313	RED
at aeba0de6f	renumbered	0.683	0.931	pass

Read the bottom two rows together. Post-4712dac40 the instrument is INVERTED:
it reds the correct code and passes the mutant, and the mutant is measurably
CLOSER to the oracle than the correct code is. 4712dac40 is right — it gives
vt's gated activations upstream's rounding polarity, and it is the only form
that reproduces the committed silu_and_mul_bf16_8x256 oracle golden bit-exactly
— so what it did here was raise this comparison's noise floor above the defect's
signal.

#1461 restores a functioning instrument: at its derived 2.0x the correct code
passes and every O(1) defect this case exists for still reds (its scatter-offset
mutation reds at 14.08x and 24.06x). It does NOT recover the renumbering
detection, and no constant can, because the ordering of the two is now reversed.

Why the states are the wrong instrument for this, upstream's own words

scripts/gen-ltx2-gemma-tower-goldens.py:363-375 already records the same shape
for partial_rotary_factor: the whole difference is 1.09e-01 against a bf16
noise floor of 9.99e-02, a ratio of 1.09, "inside the tolerance the same states
are gated at", and enlarging the fixture makes it WORSE — at (head_dim 16/32,
seq 32) the ratio falls to 0.65, "because bf16 accumulation noise grows at least
as fast as the rope contribution does". Its conclusion is that the end-to-end
states are the wrong instrument and the right one is the rope table itself, in
f32, with no accumulation in it. Position numbering is the same class of defect
and has no such case.

The physics is also on that side: rotary embedding is relative and the pads are
masked, so upstream's own f32 answers for positions 12..19 and 0..7 agree to
3.6e-06 relative. There may be nothing here worth a value gate at all.

What a repair owes

An instrument with no bf16 accumulation between the defect and the assertion.
Two candidates, in order of preference:

1. Assert the positions vector Ltx2EncodePromptToConditioning builds directly,
   against the left-padded absolute numbering, before it reaches the tower. It is
   an integer contract and it cannot be absorbed by rounding.
2. Extend the existing rope-table case, which already compares the oracle's own
   cos|sin in f32, to the padded absolute positions this path passes.

Or the finding that (1) makes the value comparison redundant for this defect and
the note should simply stop claiming coverage it does not have.

Owner: row MODEL-DIFFUSION-ltx-2-5-ltx2-video-transformer-3d-model, spec .agents/specs/ltx-2-5.md, under ## Owed.