fix(DEBTFIX): bound the glue tensor's rank, and let quant_repack see the device

[localai-org-maint-bot]

Two standing defects, each already filed, neither owned by a roadmap row, and
both invisible to every gate that runs today. Spec:
.agents/specs/debtfix-glue-rank-bound-and-repack-device.md.

#2435 — dense_attn::MakeTensor writes past vt::Tensor's fixed arrays

MakeTensor walked i from rank - 1 to 0 writing t.shape[i] and
t.stride[i], over two int64_t[4] arrays, with no bound. A rank-5 shape wrote
eight bytes past each. shape[4] lands on stride[0], which the last iteration
rewrites correctly, so the shape damage heals itself; stride[4] lands on the
three storage markers and the first iteration writes 1 there, setting
Tensor::repacked on a tensor nothing ever repacked. That is the flag
kMatmulBTQuant reads to choose the i8mm interleaved gemm over the plain one —
a wrong kernel choice waiting for a weight, not a fault, which is why no value
gate could see it.

vt::Tensor::Contiguous — the only other writer of those arrays — has carried
this bound since it was written. This closes the parallel path: one CheckRank,
called by MakeTensor and by DBuf's constructor, which needs it before
pool_->Get because a constructor that throws never runs its own destructor.

The thirteen callers are all paged-KV fixtures spelling
{2, num_blocks, block_size, num_kv_heads, head_size}. Every one takes only
.data from the buffer and carries the five extents to PagedKvCache as
separate scalars, so folding the leading K/V axis into the block axis is the same
bytes, the same element count and the same truth at a rank the type can hold.

What was red. Under this lane's -fno-sanitize-recover=all the finding
ABORTS: test_qwen4_exp_layer_loop printed one UBSan line, ran zero
assertions, and exited 1. It now runs 341 assertions and exits 0 with zero
findings. That abort is what has reddened sanitize-cpu (address,undefined).

The "384 byte leak in 4 allocations" IS a leak, and an earlier revision of this
branch said it was not. sanitize-cpu on this branch's own head named it:
test_glm_moe_dsa_schedule prints Status: SUCCESS! over 533 passing assertions
and then exits nonzero on 384 byte(s) leaked in 4 allocation(s) — under
VT_POOL_BYPASS=1, with the pool not involved. The case declares
std::vector<void*> owned, pushes all four allocations into it (128 + 128 for the
bf16 operands, 64 + 64 for the outputs) and never frees them; the same file's
Harness collects into owned_ and frees from ~Harness. Fixed with a
scope-exit guard, not a trailing loop, because RequireFinite and the REQUIREs
in that body throw and doctest unwinds. The earlier measurement was true (every
DevicePool::Get retention stack disappears under VT_POOL_BYPASS=1) and the
inference from it was not: that mechanism explains 53696 bytes in 114 allocations, never 384 in 4. The sweep that supported it was scoped to the
fifteen dense_device_glue.h includers and the leaking binary is not one.

#2406 — quant_repack was the last device-blind flag in the load policy

GgufLoadPolicy::FromEnv resolved it from vt::cpu::QuantRepackActive(), a pure
host-ISA probe. On an aarch64 i8mm host with a GPU — dgx GB10 and Jetson Thor,
both fleet devices — a --device cuda load repacked Q8_0 weights into the ARM
block_q8_0x4 interleave and staged them to a card whose quant kernels read
plain block_q8_0. Its sibling elem_kn_repack has carried dev == kCPU for
exactly this reason since it landed.

The device gate, not the dequant, and the reasons are in the spec. #2406 also
records dequantizing the qwen4_exp hyper-connection weights at load, which
mirrors vLLM and would remove all 194 repack-hazard tensors of the released
artifact at once. Rejected here because: the defect is in the policy line, not in
one architecture's tensors, and the gate fixes it for qwen3_5, glm5_next,
glm_moe_dsa, deepseek_v4 and laguna too; on dev == kCPU the gated
expression is character-for-character the old one, so the released artifact's
--device cpu control cannot move, while a dequant replaces kMatmulBTQuant
with a bf16 GEMM on 194 weights and would have to re-earn it on a box no wave
here has a lease for; and the upstream evidence for the dequant is a forward
reference 1,465 commits past the parity pin that states no position on the GGUF
arm, because vLLM loads safetensors and never meets a Q8_0 HC weight. The dequant
is recorded as owed, not refused.

QuantRepackForDevice takes the ISA answer as a parameter rather than
calling it, because QuantRepackActive() is a compile-time false off aarch64:
an assertion routed through FromEnv would pass on x86 whether the device term
existed or not. That is the move RouteGgufTensor already made for dev.

Four comments that asserted the defect away are corrected in place, including
"measured harmless on the target checkpoint (one Q8_0 tensor ... quant_repack = 0)" — docs/USAGE.md records the released UD-IQ1_S artifact carrying 194
Q8_0 hyper-connection weights.

THIS DOES NOT TURN sanitize-cpu GREEN ON ITS OWN

The sweep below built and ran every test file that can construct a DBuf or
call MakeTensor — the fifteen that include dense_device_glue.h or
dense_attn_block.h. No rank-5 caller survived, and no binary reports a leak.
Two of them still abort, on a finding that is not this one and that this branch
touches none of the files for:

src/vt/cpu/cpu_matmul_elem.cpp:577:61: runtime error: load of misaligned address
0x782f0e901907 for type 'const uint16_t', which requires 2 byte alignment
    #0 vt::cpu::WidenRowToF32   cpu_matmul_elem.cpp:577
    #1 RmsNormKernel            cpu_ops.cpp:557   <- the RMSNorm GAMMA
    ...
    #9 vllm::ModelRegistry::Forward   model_registry.cpp:646

test_dots3_note_attn and test_muse_glimmer_text, both through
ModelRegistry::Forward. It was hidden behind #2435 because the lane compiles
-fno-sanitize-recover=all and aborts at the first finding, and
test_qwen4_exp_layer_loop sorts earlier. Filed as #2540 and listed under
this spec's ## Owed. git diff --name-only against the base and the nine files
in those two stacks have an empty intersection.

Gates

Debug + -fsanitize=address,undefined, VT_POOL_BYPASS=1,
ASAN_OPTIONS=detect_leaks=1, re-measured on this merged head:

binary	rc	UBSan	leaks	assertions
test_qwen4_exp_layer_loop	0	0	0	341 / 341
test_device_pool	0	0	0	42 / 42
test_glm_moe_dsa_schedule	0	0	0	533 / 533, leak 384 → 0
test_gguf_keep_quant	0	0	0	10311 / 10311
test_glm5_next_bridge	0	0	0	32563 / 32563
test_glm5_next_moe	0	0	0	12731 / 12731
test_qwen4_exp_qsa_block	0	0	0	5937 / 5937
test_kv_cache_fp8_wiring	0	0	0	487 / 487
test_qwen3_dflash2_draft	0	0	0	449 / 449
test_qwen4_exp_forward	0	0	0	429 / 429
test_load_direct_upload	0	0	0	203 / 203
test_resident_weight_host_addressable	0	0	0	85 / 85
test_qwen3_5_gdn_spec_routing	0	0	0	82 / 82
test_qwen4_exp_inject_residency	0	0	0	8 / 8
test_qwen4_exp_matmul_bt_dtype	0	0	0	2 / 2
test_mistral_paged_engine	0	0	0	0 / 0, a self-declared skip: "mistral-7B-v0.3 checkpoint absent (dgx-only)"
test_dots3_note_attn	1	1	0	#2540, not this branch
test_muse_glimmer_text	1	1	0	#2540, not this branch

scripts/agent-preflight.sh --staged and scripts/agent-ready.py: no gate
failed. check-tree-compiles 805 / 805 TUs. agent-ready exits 1 only on its
--fail-on-skip rule, for the same five gates that skip on this host with no
change applied (check-arm-isa-build, check-cpu-isa-build,
check-cuda-fat-gencode, check-pr-size, check-triton-aot-multiarch).

Mutations

#	mutation	result
M1	delete CheckRank from MakeTensor	rc 1, UBSan index 4 out of bounds at the CHECK_THROWS line
M2	delete CheckRank from DBuf's constructor	rc 1, CHECK(a.allocs() == 0) reads 1 == 0 — the block really is stranded
M3	make CheckRank throw unconditionally	rc 1, ModelRegistry::Forward reaches it on a loaded qwen4exp GGUF THREW — the reachability evidence
M4	revert the FromEnv wire	rc 0, 9987/9987 — SURVIVED
M5	drop && dev == kCPU from the predicate	rc 1, the kCUDA, kROCM and kXPU rows read true == false

M4 survived and it is reported as a finding. No x86 host can tell the wired
predicate from the expression it replaced, because the ISA probe is a
compile-time false here. M5 gates the rule; the wire is gated only on an
aarch64 i8mm box, where the case's VT_GGUF_KEEP_QUANT=1 arm becomes
discriminating. Behind it stand the two runtime tripwires that already existed
and that ARE gated everywhere (test_resident_weight_host_addressable, 85/85),
so a reverted wire refuses by name rather than emitting wrong tokens.

What is not proved

The CPU control 11751 13 15767 411 2029 11 1092 369 was not re-run: thor:gpu0
belongs to another wave. It is unchanged by construction, not by measurement.
The aarch64 CUDA measurement of the repack trade that #2406 asks for is still
owed and is recorded under the spec's ## Owed.

Closes #2435
Closes #2406

Refs #2540

FOLLOWING_AGENTS_PROTOCOL

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