[devtechedge]

Summary

• Tracking Issue: Corrupt ALP-RD, RLE and RunEnd metadata can panic a file read #10756

ALP-RD's deserialize and decode paths trust stored metadata, so a corrupt or crafted file can panic a read instead of returning an error.

This covers the ALP-RD items from the issue that #10755 does not: deserialize now bounds-checks the stored dict_len against the stored dictionary, and validate rejects a dictionary longer than MAX_DICT_SIZE and a right_bit_width at or above the float's bit width, which is the bound the decode shift requires.

Left-parts codes are checked on first use: alp_rd_decode scans the codes once before decoding, and scalar_at uses a checked lookup, because both decode paths index (or mask into) the dictionary with each code.

The left_parts_ptype and RLE items from the issue look like they belong to #10755, so they are not touched here.

Partially addresses #10756.

Changes

• deserialize bails when dict_len exceeds the stored dictionary entries.
• validate_parts rejects dictionaries above MAX_DICT_SIZE and a right_bit_width at or above the float's bit width, covering deserialized and in-memory arrays.
• alp_rd_decode errors on a left-parts code outside the dictionary before decoding.
• scalar_at uses a checked dictionary lookup.

Each check has a regression test that feeds corrupt metadata through the plugin deserialize path, which is the same door a file read uses, plus a first-use test for an out-of-dictionary code and a control showing valid metadata still decodes.

The repro from the issue panics on develop and returns an error with this change.

The suite for vortex-alp passes locally (179 tests), along with clippy and fmt on the pinned toolchains.

This change was developed with AI assistance (GLM-5.3); I reviewed the diff, ran the tests, and stand behind it.