cuda: keep quantized K/V type in the short-query MMA FA path

[bri-prism]

What

One-line fix in ggml/src/ggml-cuda/fattn.cu: the short-query special case added in #189 (quantized V, 3-4 query rows) now passes type_KV through to ggml_cuda_flash_attn_ext_mma_f16_case. Also adds short-query FLASH_ATTN_EXT cases to test-backend-ops (nb 1-8, GQA 2 and 4, f16/q8_0/q4_0 K/V, head size 128 and 256).

Why

With q8_0 for both K and V, 3-4 row batches produced garbage on CUDA. Speculative decoding hits this on every verify step (target token plus 2 drafts), so MTP with -ctk q8_0 -ctv q8_0 gave 0% draft acceptance and corrupted output. Plain decoding, prompt processing and q8_0 on K only were fine. Metal was fine.

The special case called the F16 instantiation of the MMA kernel. That variant converts K/V to f16 into scratch right after dst. For K/V types that have the in-place quantized kernel (q8_0/q4_0 at head size 128/256), ggml_cuda_flash_attn_ext_get_alloc_size reserves no scratch, so the conversion wrote over neighbouring tensors.

Passing type_KV makes these types use the in-place kernel at the same 64/ncols2 tile, which is the instantiation that already exists for them. Other quantized V types still go through the F16 path, and for those the scratch is reserved.

Testing (H200, sm90)

• New FA cases, kv 256/1024 and nb 1-5 subset: 120/120 pass with the fix. Before the fix the same run hung.
• llama-server with an MTP draft head, --spec-draft-n-max 2, q8_0 K and V: before the fix, 0 drafts accepted and garbage text. After the fix, acceptance matches the f16 KV run (e.g. 15/16 and 14/14 on short code and JSON prompts), and the output matches plain f16 decoding wherever f16 MTP itself matches.

[bri-prism]

Full new-case run at 1346e6d on H200: 216/216 FLASH_ATTN_EXT short-query cases pass (kv 256/1024/4096, nb 1-5 and 8, GQA 2/4, f16/q8_0/q4_0, hs 128/256).