ROCm grouped keep-quant GEMM drops Q8_0 when the kROCM provider takes over

[localai-org-maint-bot]

Row: GFX1100-TG200

#2782 moves OpId::kMatmulBTQuantGrouped on kROCM from
MatmulBTQuantGroupedKernelRocm (src/vt/rocm/rocm_grouped_gemm.hip, renamed
*Gdn there) to the new provider in src/vt/rocm/rocm_quant_dot.hip.

The new provider delegates Q4_K/Q5_K/Q6_K back to the *Gdn kernel but not
Q8_0. Q8_0 also has no arm in rocm_quant_dot.hip: it dots a Q8_0
activation, not a Q8_K super-block, so IsRocmKeepQuantSupported(kQ8_0)
answers no. A grouped Q8_0 expert GEMM therefore throws
"no keep-quant kernel for dtype q8_0" on a path that main serves today.

The scalar arm is unaffected: MatmulBTQuantKernelRocm routes Q8_0 to its own
MatmulQ8_0Rocm.

tests/vt/test_rocm_quant_dot.cpp cannot see it because its kCases table
carries the ten Q8_K-family encodings and no Q8_0.

Found while reviewing #2782. Fixed in the same flow, in that pull request.

[localai-org-maint-bot]

Correction to the last line: "Fixed in the same flow, in that pull request" is not
where the fix ended up.

It was pushed to #2782's branch first and then reverted there, because #2782 is the
base of a seventeen-branch stack and a commit on it turned 17 of 22 clean merges into
21 conflicts, all on the two files it touches. The revert restores that branch's tree
byte-for-byte, so the downstream three-way merges go clean again.

The fix instead lands on row/EXTPR-REPAIRS-2026-09-05, merged immediately after
#2782, which costs no conflict resolution at all. Same two changes: kQ8_0 joins the
delegation list in MatmulBTQuantGroupedKernelRocm, and a q8_0 row joins the test's
encoding table so the grouped case fails if the delegation is dropped again.

This issue closes with that merge, not with #2782.