reject jpeg scans referencing an undefined huffman table

[metsw24-max]

The JPEG decoder reads each scan component's DC and AC Huffman table numbers from the SOS marker and only checks that they fall in 0 to 3, never that a DHT marker actually defined the selected slot. The JpegHuffman tables held in the decode context are not zero-initialised, so a file whose scan points at a table that was never built runs the entropy decoder over uninitialised state: the slow path in JpegHuffmanDecode forms a symbol index from the garbage delta[] and returns values[] at that index, reading well past the end of the context. I ran into it while fuzzing SimdImageLoadFromMemory under AddressSanitizer, which reports a heap-buffer-overflow read in JpegDecodeBlock on a crafted three-component baseline image whose third component selects an undefined DC table. Checking the selectors against the tables that were actually defined, at the scan header once it is known which tables the scan will use, rejects such a file before decoding and lines up with how libjpeg treats an undefined table. The DC table is only consumed by the first DC scan and the AC table only by the AC scans, so the check follows that split to avoid rejecting valid progressive files that name an unused selector. I applied the same guard to the AVX2 decoder, which keeps its own scan-header parser.