Fix division by zero in JPC packet iterators

[iliasabk]

Summary

Fixes #420 — a crafted JPC codestream causes a division by zero (SIGFPE) in the packet iterators.

Root cause

In jpc_pi_nextrpcl, jpc_pi_nextpcrl, and jpc_pi_nextcprl, the precinct-size products

• pi->picomp->hsamp << rpx / pi->picomp->vsamp << rpy (divisors in the modulo tests)
• pi->picomp->hsamp << r / pi->picomp->vsamp << r (divisors in JPC_CEILDIV)
• trx0 << r / try0 << r and 1 << rpx/1 << rpy (modulo operands)

are all computed in uint_fast32_t. The existing guard only bounds precinct exponent + numrlvls; it does not account for the up to 8 extra bits contributed by the component sampling factors hsamp/vsamp (range 1..255 from the SIZ marker). With e.g. hsamp = 96 and rpx = 27, 96 << 27 wraps to 0 modulo 2^32, and the subsequent % (hsamp << rpx) divides by zero — SIGFPE on i386 (and a UBSan report elsewhere).

The same overflow affects the xstep/ystep products hsamp * (1 << k) in all three functions: the wrapped value can be zero (rejected by the existing check) or silently wrong.

Fix

• Compute all of the above products in uint_fast64_t, preserving the mathematical semantics for every input — no valid codestreams are rejected.
• Compute xstep/ystep in uint_fast64_t and saturate to UINT_FAST32_MAX; a step that exceeds the representable range behaves as before (a single iteration over the tile).

Testing

• Reproduced the issue with the PoC from graphicsmagick:coder_JPC_fuzzer: Floating-point-exception in jpc_pi_next #420 (hsamp=96, rpx=27 → hsamp << rpx == 0 → runtime error: division by zero under UBSan).
• With the patch, the same input no longer triggers any sanitizer report; decoding fails gracefully.
• Sweep over data/test (40 files): no new sanitizer reports; the 4 remaining hits are pre-existing issues in jpc_dec.c/jas_image.c on files from the bad/ corpus, unrelated to this change.