ROCm ports zero I-quant formats, and porting a complex-vec_dot one would test whether #1910's nwarps split transfers

Row: KERNEL-QUANT-CIQ-GEMM-ROCM-IQUANT

src/vt/rocm/ ports zero I-quant formats. MatmulBTQuantKernelRocm's refusal
message at rocm_grouped_gemm.hip:495 names the gap directly:
"ported: Q8_0/Q4_K/Q5_K/Q6_K; owed: Q4_0/Q2_K/Q3_K/IQ2_XXS/IQ3_XXS/IQ2_S/MXFP4".
The grouped launcher's refusal at :565 repeats the same list.
.agents/specs/rocm-gg-keep-quant.md ## Boundaries already records this gap,
but no issue has tracked it until now.

What already exists to port from

CUDA and CPU both implement five I-quant formats. Porting each of these five
is an adaptation of existing source, not a from-scratch port.

CPU and CUDA do not port IQ1_M, IQ2_XS, IQ3_S, IQ4_NL, or IQ4_XS
either. Those five need a fresh port from the llama.cpp oracle instead of an
adaptation.

All five already-ported formats use the same 256-element superblock and the
same BlockQ8_K activation format as Q4_K, Q5_K, and Q6_K
(kQK_K, rocm_grouped_gemm.hip:41). A ROCm port of any of them dispatches
through the identical nsb = K / 256 decomposition that
#1910 covers, including its
lane-idle defect at small nsb, if that row lands first.

Why this is more than coverage

#1910 ports llama.cpp's
nwarps-scaling decode dispatch from ggml/src/ggml-cuda/mmvq.cu, pin
10bf611e5, tag b10451. That table splits by vec_dot complexity. Q4_K,
Q5_K, and Q6_K use a linear scale and minimum, and get nwarps=8 on
RDNA4. llama.cpp excludes Q3_K and the IQ2 and IQ3 families by name,
because their vec_dot does a grid lookup. The comment at mmvq.cu:387-388
states the reason: it regresses from register pressure and lookup table
contention at higher thread counts.

We have no data on whether that split holds for our own dot product bodies.
The existing spec rocm-kquant-nwarps-decode.md measures only the simple
side. Porting IQ2_XXS or IQ3_XXS gives a complex vec_dot body to run the
same nwarps sweep against on real gfx1200 hardware. Both formats are
already adaptable from the CUDA source above, so this tests llama.cpp's
split against our own kernel bodies instead of assuming it transfers from a
different vec_dot implementation on different hardware.

What is NOT established

• Whether the HIP translation of DotIQ2XXS or DotIQ3XXS compiles to
  efficient code on gfx1200. The grid lookup dequant can use different
  constant memory or cache behavior on RDNA4 than on the NVIDIA and CDNA
  hardware that tuned llama.cpp's table.
• No speed or correctness claim is made here. This issue states scope and
  motivation only.
• The keep-quant loader wiring, the dequant table adaptation from
  cpu_quant_iq_tables.h and cuda_quant_iq_tables.cuh to a ROCm
  equivalent, and the correctness tests are all unstarted.

Owned by BACKEND-ROCM.

Start with src/vt/rocm/rocm_grouped_gemm.hip, especially the refusal messages at lines 495 and 565, then compare DotIQ2XXS and DotIQ3XXS in cuda_quant_dot.cu with their listed llama.cpp oracle sources. Read the keep-quant and nwarps specs before adapting the dequant tables, loader wiring, and correctness coverage. Done means the five listed I-quant formats are supported on ROCm and IQ2/IQ3 nwarps behavior is measured on gfx1200.