PTQ1_0 Vulkan path falls back to generic LUT decode on int-dot-less devices (gfx1013)

[renovys]

• Device: AMD BC-250 (gfx1013, RDNA1, warp 32, matrix cores none, int dot: 0, RADV/Mesa).
• File: Ternary-Bonsai-2-27B-PTQ1_0.gguf, vulkan: integer-dot mat-vec kernel for PTQ1_0 (8x faster decode) and PQ2_0 support #188 build.
• Repro: llama-bench -m <PTQ1_0.gguf> -ngl 99 -fa 1 -p 512 -n 128 -r 3 on Vulkan0.
• Observed: decode ~4.8 t/s with vulkan: integer-dot mat-vec kernel for PTQ1_0 (8x faster decode) and PQ2_0 support #188 alone, ~8.2 t/s combined with vulkan: speed up PTQ1_0 decode (trit table + vectorized dequantize4) and add MUL+FWHT fusion #187; no integer-dot pipeline is created and the generic LUT decode path is used (the accelerated PTQ1_0 mat-vec in vulkan: integer-dot mat-vec kernel for PTQ1_0 (8x faster decode) and PQ2_0 support #188 needs int-dot).
• By contrast PQ2_0 on the same box runs at ~24 t/s (see vulkan: integer-dot mat-vec kernel for PTQ1_0 (8x faster decode) and PQ2_0 support #188 comments, and the gfx1013 tuning in vulkan: tune the PQ2_0 mat-vec for AMD BC-250 (gfx1013, RDNA1) #229).
• Suggestion: either document that PTQ1_0 needs int-dot to be viable, or add a tuned no-int-dot generic path so RDNA1-class devices (gfx1013 and similar) stay usable on PTQ1_0.
• Willing to re-test patches on gfx1013.