zero-fill deep sample-count table for zero-length compressed input

[cary-ilm]

A crafted compressed deep-scanline (or deep-tiled) EXR chunk that declares a zero-length sample-count table causes exr_decoding_run() to read uninitialized heap memory in unpack_sample_table().

exr_read_scanline_chunk_info() rejects a negative sample-table size but accepts zero for compressed deep chunks. default_read_chunk() only allocates and reads packed_sample_count_table when the declared size is greater than zero, so it stays NULL. update_pack_unpack_ptrs() still allocates the full decompressed sample_count_table (width * height * sizeof(int32_t)) without initializing it, and exr_uncompress_chunk() skips decompress_data() entirely when packed_sample_count_table is NULL. The existing zero-fill safeguard in exr_decoding_run() only covered EXR_COMPRESSION_NONE, so for any other compression type the uninitialized buffer was passed straight into unpack_sample_table(), which reads it to check sample-count monotonicity and compute the total sample count.

Fix: when a compressed deep chunk has no packed sample-count table (packed_sample_count_table == NULL, i.e. the declared table size is zero), zero-fill the allocated sample_count_table before unpack_sample_table() runs, treating the absent table as all-zero sample counts instead of leaving it uninitialized. This matches the remediation suggested in the advisory report.

Addresses https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-prr3-4q3r-hmf3