Validate reconstruct kernel indices before dispatch

[professor-moody]

Summary

reconstruct_slice and reconstruct_had_slice select CUDA kernels by indexing fixed 24-entry function-pointer tables. The index is derived from K, which ultimately comes from the EXL3 checkpoint's trellis shape, but neither dispatch site currently checks that K is within the supported range.

This change validates K as 1..8 before any size arithmetic, then validates the computed index before dispatch. Invalid K values reaching either reconstruct entry point now produce a RuntimeError instead of indexing outside the reconstruct kernel table.

This addresses the issue coordinated as CERT/CC VU#369611 and discussed in #250.

Validation

The affected reconstruct.cu blob on current master (0c49587a7c235e6303a6bbedc8b665272ad3a2ea) is byte-identical to the source used for the A100 validation. This uses the same validated guards, with the K check moved ahead of the existing 256 * K / 16 size expression so malformed values cannot reach that arithmetic first.

On the patched A100 build:

• valid K=1, K=4, and K=8 boundary/control cases returned normally;
• invalid K=0 and K=9 cases were rejected with RuntimeError: K must be in 1..8 in both reconstruct dispatch paths;
• the corresponding unpatched cases reached a non-zero exit or CUDA illegal-memory-access result; and
• turboderp/Llama-3.2-1B-Instruct-exl3 at 2.0 bpw loaded and generated normally.

The compatibility check covers that tested checkpoint and configuration; it is not intended as a survey of every EXL3 model.

Scope

The patch changes only the two load/reconstruct dispatch sites. It does not alter valid kernel selection or model output.

AI assistance was used while preparing the patch and validation. I reviewed the change and am responsible for it.

[laurie-tyz]

Thanks for providing the link in the case!

[turboderp]

Thanks. I'm not sure how you'd end up with a bitrate less than 1 or greater than 8, but it can't hurt to bounds check.