ResidentWeight's device-staging arm drops q8_0_aligned and repacked while guarding elem_kn_repacked

Row: -

ResidentWeight's device-staging arm in include/vllm/model_executor/models/dense_attn_block.h guards one storage-layout marker loudly and drops the other two silently.

The arm ends in return MakeTensor(w.d_dev.get(), w.dtype, d.q.device, shape);. MakeTensor does not copy repacked, q8_0_aligned or elem_kn_repacked (include/vt/tensor.h:29,39,54). The CPU host-alias arm directly above it propagates repacked and elem_kn_repacked by hand, and carries a long comment saying why — that propagation is the #2031 fix, landed at 7a937db8a, after a dropped marker made an i8mm-interleaved block_q8_0x4 buffer decode as flat q8_0, giving NaN, then all-zero logits, then token id 0, with nothing logged because the lm_head GEMM swallowed the NaN.

The staging arm handles the three markers inconsistently:

• elem_kn_repacked — guarded. VT_CHECK(!w.elem_kn_repacked, ...) refuses at load, on the correct grounds that VT_CPU_ELEM_KN_REPACK is a CPU-only transform.
• repacked — neither guarded nor propagated. Like the above it is a CPU-only layout (vt::cpu::QuantRepackActive() is true only on aarch64 i8mm), so it arguably deserves the same refusal, but nothing says so.
• q8_0_aligned — neither guarded nor propagated, and it is not CPU-only. This is the one that matters.

q8_0_aligned is a device flag. src/vt/cuda/cuda_quant_dot.cu reads it at :2272, :2283, :2307, :2326, :2685 and :2732, and at :2326 it selects the coalesced-load layout produced by RepackQ8_0Cuda ("Brick 4", aligned int4 loads). It is set by qwen3_5_gguf_weights.cpp, qwen3_5_weights.cpp, deepseek_v4.cpp, qwen4_exp_moe.cpp and glm5_next_bridge.cpp.

Two consequences, and I have not established which is live:

1. If a q8_0_aligned weight reaches a CUDA Q8_0 GEMM through this helper, the bytes are in the repacked layout and the flag says they are not. The kernel then reads repacked bytes as plain. That is #2031 again, on the device side, and it is silent.
2. If nothing currently routes such a weight through this helper, then the capability is simply unreachable through the shared seam: every model that inherits it takes the generic path and never the aligned one. That is a performance loss rather than a correctness bug, but it is invisible either way.

src/vllm/model_executor/models/qwen3_5.cpp keeps a private copy of this helper that carries the markers (:1055, :1060), which is exactly how #2031 stayed hidden for twelve waves: the model exercising the lever hardest never used the lossy shared helper, while the models that inherit it did.

Found while repairing a review finding on MODEL-MM-deepseek-v4-deepseek-v4-for-causal-lm (#2411), where the same defect had been reintroduced in a private BorrowResidentWeight. That instance is fixed by propagation rather than refusal, since a fail-closed check there would have removed the CPU i8mm fast path instead of fixing the loss. This shared-seam instance is outside that row's scope and is recorded under its spec's ## Owed.

Whoever takes this should decide per marker rather than uniformly: refusal is right for a CPU-only transform reaching a device, and propagation is right for a device-relevant layout. Establishing which of the two consequences above is live is the first step, not the fix.

Start in include/vllm/model_executor/models/dense_attn_block.h at ResidentWeight's device-staging arm, then compare the host-alias arm and the private helper in src/vllm/model_executor/models/qwen3_5.cpp. Trace q8_0_aligned through src/vt/cuda/cuda_quant_dot.cu and the listed weight loaders to establish whether the shared path is live. Done means CPU-only markers are handled explicitly and q8_0_aligned reaches the CUDA GEMM with its layout marker intact, with the relevant behavior verified.