GGUF kernels: raise on unsupported quant type instead of returning uninitialized memory

[vcruz305]

Splitting this out of #131 because it stands on its own and is quick to review. It is a correctness fix with no feature attached.

None of the five switch (type) blocks in gguf_kernel.cu has a default: case, and the output tensor is allocated with torch::empty. So passing a quant type the kernel does not implement returns uninitialized memory instead of raising:

at::Tensor Y = torch::empty({batch, row}, options);   // uninitialised
switch (type) {
  case 2:  ...
  case 14: ...
  // no default -> Y returned as-is
}
return Y;

ggml_moe_get_block_size has the same shape and falls through to return 0, which then divides or sizes a launch by zero downstream.

The gap is real rather than theoretical. ggml_mul_mat_vec_a8 and ggml_moe_a8_vec handle 19 types, while ggml_mul_mat_a8 and ggml_moe_a8 handle 10: the I-quants have no MMQ kernel. So any caller that routes an I-quant to the MMQ path today gets silent garbage, and the only symptom is a model that loads fine, runs at full speed and emits fluent nonsense. I lost a fair amount of time to exactly that before adding these guards.

Each default: now raises through TORCH_CHECK and names the function plus which type families that entry point actually supports. I also null-check the ggml_get_to_cuda function pointer inside ggml_dequantize, since it returns nullptr for an unknown type (dequantize.cuh) and the result was being called unconditionally.

No kernel math is touched. The only behaviour change is that an unsupported type now fails loudly at the call instead of producing wrong numbers. There is a comment above the first guard noting these kernels are vendored from sgl-kernel and that the guards are a local addition, so a future re-vendor does not quietly drop them.

Found while working on #131 (GGUF quant types and qwen35moe), but it is independent of that branch.

[paralin]

Failure exists on any backend where an unsupported quant path falls through, +1