The three LTX-2.5 decode dispatch sites share one cursor, so reverting any single one is detected by nothing

[localai-bot]

Reverting any single one of the three parallel dispatch sites that
#1009 added to the LTX-2.5
conv video VAE is detected by nothing in this tree. Only reverting all three
goes red.

What is actually gated today

LTX25-DECODE-THREADS (PR #1041)
routes three loops through vt::cpu::ParallelForRows
(src/vt/cpu/cpu_threadpool.cpp:413):

1. CausalConv3d's padding gather (src/vllm/model_executor/models/ltx2_video_vae.cpp:170)
2. CausalConv3d's output nest (:218)
3. Linear3d (:276)

The instrument is the test case "ltx2 vae: the decode DISPATCHES its
convolutions to the CPU threadpool"
(tests/vllm/models/test_ltx2_vae.cpp), which reads the pool's shared
work-stealing cursor through the non-mutating Threadpool::ChunkAdd(0) and
checks it moved off zero.

One cursor is shared by the whole pool. ParallelForRows seeds it with
tp.ChunkSet(nth) from worker 0 (cpu_threadpool.cpp:438) and advances it with
ChunkAdd(1) on every steal (:455), so reverting one site leaves the other two
dispatching and the cursor still reads non-zero. The case therefore gates "at
least one of the three sites dispatches partitioned work", never each site
individually.

Measured, three facts per mutation, in the row's spec
.agents/specs/ltx25-decode-threads.md §8.6 and reproduced independently by the
row's reviewer:

mutation	built	: error:	ctest exit	detected by
T0 — all three reverted	yes	0	1	the dispatch case, CHECK( 0 > 0 )
T1 — the output nest alone	yes	0	0	nothing
T2 — the padding gather alone	yes	0	0	nothing
T3 — Linear3d alone	yes	0	0	nothing

Why this is a gap and not a correctness hole

A silently serialised site is a performance regression. Correctness stays
fully gated: 34 golden margins came back byte-for-byte identical across the
change, the bit-identity case memcmps five worker counts, and ThreadSanitizer
is clean against an 84-race positive control. Nothing here can produce wrong
pixels. What it can do is quietly give a site's parallelism back and leave the
suite green, and the only thing that would notice is a wall-clock nobody runs in
CI.

The closing test

Add a per-dispatch counter to Threadpool — RunCount(), bumped in Run()
(src/vt/cpu/cpu_threadpool.h:112; there is no such counter today) — and assert
an exact expected count for a fixed fixture, not > 0. Reverting any one
site then lowers the count and the case goes red.

Two things the implementer has to handle:

• Run() is not reached on every call. ParallelForRows short-circuits to
  body(0, nr) without touching the pool when nr == 1 or
  tp.NThreads() == 1 (cpu_threadpool.cpp:423-424), so the fixture must keep
  every site's row count above 1 for the expected number to be a constant. On
  today's MakeLtx2ThreadFixture the four reachable dispatches are conv_in's
  gather (nr = 35) and output nest (nr = 360) and conv_out's gather
  (nr = 840) and output nest (nr = 15), which derives an expected 4 —
  that arithmetic is from the fixture's declared shape and has not been run, so
  confirm it red-first rather than porting the number.
• T3 needs a different fixture. MakeLtx2ThreadFixture sets
  decoder_blocks = {}, and Linear3d is only reached through a res_x_y
  block, so Linear3d is not on that fixture's path at all. Closing T3 needs a
  fixture carrying a res_x_y block — the "Conv video decoder" golden already
  has one and is the obvious donor.

Not fixed in flow, and why

#1009's row is reviewed and passing. Adding a gate is a semantic change to what
the suite proves and needs its own red-before evidence and its own fresh review,
which is the normal row path rather than an in-flow repair. Owned by
LTX25-DECODE-THREADS and listed under that spec's ## 7. Owed.