Hybrid placement: routed-expert towers placed on the host load UNREPACKED, because quant_repack is per-load and reads the engine device

Row: ENG-HYBRID-PLACEMENT

What

GgufLoadPolicy::quant_repack is a single per-load flag, resolved once from
the ENGINE device:

// src/vllm/model_executor/model_loader/gguf_keep_quant.cpp:383
p.quant_repack = QuantRepackForDevice(p.keep_quant, p.cpu_ref,
                                      vt::cpu::QuantRepackActive(), dev);

and QuantRepackForDevice is gated dev == vt::DeviceType::kCPU
(gguf_keep_quant.cpp:94-98).

So on an aarch64 host with a CUDA engine and routed experts placed on the
CPU, p.quant_repack is false — and the ten weight loaders that read
pol.quant_repack per tensor therefore load those towers unrepacked, even
though the placement plan has sent them to a host whose i8mm vec_dot is the
whole reason the repack exists. glm5_next_bridge.cpp:118 and :248 both say
the flag "is set on every aarch64 i8mm host"; under hybrid placement that
sentence is no longer true of the tensors it describes.

Why it is filed now and not fixed

#2516 made Route/PeekRoute resolve a routed-expert tower's RESIDENCY against
the device that will execute it (GgufLoadPolicy::ComputeDeviceFor). That was
per-tensor and could be. quant_repack cannot be resolved the same way without
becoming per-tensor state, which is a change to the policy struct's shape and
to every one of its consumers — a different unit of work.

This is throughput, not correctness. An unrepacked tower still decodes
through the same vec_dot; the repack is a layout optimisation. The !!!!!!!!
degenerate-output defect earlier in this campaign was a bug IN the repack, not a
dependency on it.

Not yet measured

No number is claimed. The cost is whatever the i8mm repack is worth on the
placed towers, and on GB10 that is the GLM-5.3 expert-streaming path, so it is
worth measuring before it is worth fixing. Reproduce with an aarch64 CUDA engine
plus VT_CPU_MOE=1 and compare pol.quant_repack against a --device cpu load
of the same checkpoint.

Read src/vllm/model_executor/model_loader/gguf_keep_quant.cpp at lines 94-98 and 383, then inspect the ten loaders that consume pol.quant_repack and the references in glm5_next_bridge.cpp at lines 118 and 248. Reproduce on an aarch64 CUDA engine with VT_CPU_MOE=1, compare against a --device cpu load of the same checkpoint, and quantify the placed-tower throughput difference before deciding whether the policy change is worthwhile.