row/MODEL-DIFFUSION-LTX25 is RED on the device-leakage DSR ratchet: ltx2_video.cpp adds two kcuda sites to the shared layer

[localai-bot]

scripts/check-device-leakage.py fails on the kcuda bucket for every PR opened
against row/MODEL-DIFFUSION-LTX25, because the branch itself carries two
device-specific references in the device-agnostic shared layer where the
baseline is 0:

src/vllm/multimodal/ltx2_video.cpp:404: [kcuda] vt::Backend* backend = vt::TryGetBackend(vt::DeviceType::kCUDA);
src/vllm/multimodal/ltx2_video.cpp:421: [kcuda] im.device = vt::Device{vt::DeviceType::kCUDA, index};
DSR by bucket: kcuda=2, is_cuda=0, cuda_inc=0, vt_ifdef=32  -> total 34
ERROR: DSR REGRESSION in bucket 'kcuda': 2 > baseline 0.

Both lines are present verbatim at f400413ef (the branch tip), so this is the
branch's own debt and not a regression from any PR that merely bases on it.
Confirmed while landing #548 (row LTX25-L9B-RENDER), whose diff touches
neither file: git show f400413ef:src/vllm/multimodal/ltx2_video.cpp | grep -n 'DeviceType::kCUDA' prints exactly those two lines.

They arrived with phase L8's device wiring. The engine maps params.device != 0
onto a CUDA device directly, which is precisely what the checker's message says
to avoid: the question belongs to the platform/provider table
(vt::OpRegistered / Platform capability), and a genuine platform leg belongs in
ALLOWLIST with a reason. Note the surrounding refusal is deliberate and good
(it refuses to serve the CPU forward behind a CUDA-looking handle); only the way
it names CUDA is the problem, so this is a rewrite of two lines plus an
allowlist decision, not a behaviour change.

Not fixed in #548: that PR is the render driver and the --video-family flag,
and per AGENTS.md a fix that "would surprise a reviewer" takes the normal
row/spec/fresh-review path rather than riding along.

Related: #435 (the LTX-2.5 campaign). Prior instances of this ratchet firing:
#298, #302.