The entire trueno Q4_K GEMV module (AVX-512 branch included) is dead-code-eliminated from the shipped apr binary #2611

Severity: P2 — found by the pre-release multi-platform dogfood sweep (intel/AVX-512 lane).

Measured against the published apr 0.63.0 from crates.io on the Intel receipt host
(Xeon W-3245, 16C/32T, AVX-512F/BW/CD/DQ/VL/VNNI), not a local build.

Where

crates/aprender-compute/src/backends/q4k/gemv/{mod,avx512,avx2,scalar}.rs — the exact file the sweep was pointed at (gemv/mod.rs:53)

Defect

The entire trueno Q4_K GEMV module, AVX-512 branch included, is NOT PRESENT in the shipped apr binary — it is dead-code-eliminated because nothing in the CLI reaches it. So the AVX-512/AVX2/scalar dispatch this sweep was sent to adjudicate cannot be exercised through apr at all, on any host; the three prior platform receipts could not have exercised it either. The real Q4_K path is realizar::quantize (F1). Two secondary notes on the module now that it is confirmed unreachable: (a) its dispatch returns to matmul_q4k_f32_parallel for total_work >= 8_000_000 BEFORE the AVX-512 check, so every FFN and lm_head shape skips the AVX-512 branch in the serial dispatcher — but unlike aarch64 (#2567) the per-chunk closure DOES dispatch to avx512::compute_chunk_q4k_avx512, so x86's _parallel is genuinely parallel and vectorised, and the #2567 scalar-under-a-parallel-name defect does NOT replicate here; (b) this makes any contract coverage claimed for avx512-q4k-v1.yaml (C-AVX512-Q4K-001/002) untested through the shipped artifact.

Reproduction

MEASURED on mac-server against the published binary (NOT stripped, 125,894 symbols, so absence is meaningful):
  nm /home/noah/.cargo/bin/apr | grep -c compute_chunk   -> 0
     (no compute_chunk_q4k_avx512 / _avx2 / _scalar — these are #[target_feature] fns called from a
      non-target-feature closure, so they CANNOT be inlined away; absent means unreachable)
  nm … | grep -c matmul_q4k                              -> 2, and both are realizar's:
        realizar::apr_transformer::AprTransformer::seq_matmul_q4k
        realizar::apr_transformer::AprTransformer::matmul_q4k_or_f32_traced
  nm … | grep '6trueno' | grep -i q4k                    -> 2 hits, neither is gemv:
        trueno::tiling::q4k_matvec::TiledQ4KMatvec::execute_parallel (rayon drop_glue)
        trueno::backends::gpu::device::linalg::wgsl_forward::WgslForwardPass::upload_q4k_weight
  nm … | grep -oE '[A-Za-z0-9_]*gemv[A-Za-z0-9_]*'       -> only trueno::blis::gemv::{gemv, gemv_scalar,
                                                             gemv_avx2, gemv_tiled_avx2}  (also no AVX-512)
POSITIVE CONTROL that the linker does keep reachable #[target_feature] fns:
  realizar's fused_q4k_q8k_dot_avx512vnni_v2 (0x182f740) and _4rows_avx512vnni (0x182ffc0) ARE present.
SOURCE PINNED: git diff v0.63.0 -- crates/aprender-compute/src/backends/q4k/ is EMPTY, so the working
tree I read is the published source.

Filed from the 0.64.0 pre-release sweep. Scope SHARED.