Fix CCITTFactory.readlong

[valerybokov]

Summary

CCITTFactory.readlong() reads a TIFF LONG field (an unsigned 32-bit value per the TIFF spec) by assembling four bytes with an int, then returning that int. At the call site (long address = readlong(...)), the int is widened to long, which in Java sign-extends. If the top bit of the 32-bit value is set (i.e. the raw value is >= 0x80000000), the widened long becomes a large negative number instead of the correct unsigned value — corrupting IFD offsets used directly in reader.seek(address).

In practice this is latent rather than commonly hit: classic TIFF (non-BigTIFF) is capped near 4GB by its own 32-bit offset fields, and CCITT G3/G4-compressed files in particular are typically KB-to-low-MB in size, so authentic offsets essentially never cross that boundary. The realistic risk is a malformed/corrupted/adversarial TIFF whose 4-byte offset or count field has the high bit set — readlong trusts those bytes without validating against the actual file size, so such input silently produces a corrupted negative seek target rather than a controlled error.

Fix

• fix warning for readlong method
• readlong now returns long and masks the assembled value with & 0xFFFFFFFFL, so it's always treated as unsigned when read.
• address (already declared long) now receives the correct unsigned value automatically.
• count and val, which are intentionally kept as int (small tag values used with params.setInt(...) / buffer sizes), now narrow explicitly via (int) casts — same bit pattern as before, so their behavior is unchanged.

Test plan

Added CCITTFactoryTest#testReadLongIsUnsigned, which invokes the private readlong via reflection against crafted byte sequences with the high bit set (0xFFFFFFFF and 0x80000000, in both byte orders) and asserts the returned long is the correct non-negative unsigned value.

• Verified the test fails against the pre-fix int-returning implementation (e.g. expected 4294967295, got -1) and passes against the fix.
• Existing CCITTFactoryTest suite (small real-world CCITT G3/G4 fixtures) continues to pass — those files never exercised this path since their offsets are well under 0x80000000.