use size_t for slice size when packing array slices

[sahvx655-wq]

When packing a 3D image from a set of 2D slices, load_uncomp_file() reads each slice's dimensions from its file header and works out the per-plane copy length as slice_size * 4, with slice_size held in a plain int. dim_x and dim_y come straight from the KTX/DDS/PNG slice headers, so they are untrusted; once a slice reaches around 24576x24576 the dim_x*dim_y product still fits an int but slice_size * 4 overflows the signed type, and the negative intermediate is promoted to a size_t close to SIZE_MAX before it reaches memcpy. I spotted this auditing the array path after the recent alloc_image size_t change: the destination plane is now allocated at its true 64-bit size while the copy length wraps, which is the usual heap-overflow signature.

Holding slice_size as a size_t keeps the byte maths in 64-bit and lines the copy length up with the width alloc_image already uses for the same plane. Keeping the calculation here, beside the slice load and the plane allocation, means the packer does not rely on each loader having pre-checked the texel count first. Left as is, a crafted set of large slices walks a memcpy off the end of both the source slice and the destination plane on an ordinary -array load.