Fix chr() deprecation in ASCII85 last-tuple decoding

[Ciki]

Problem

PR #779 fixed the chr() deprecation warning in the main ASCII85 decoding loop but missed the "last tuple" switch/case block (handling incomplete groups at the end of encoded data).

The same issue applies — bit-shifted values ($tuple >> 16, $tuple >> 8) can exceed 255, triggering:

chr(): Providing a value not in-between 0 and 255 is deprecated, this is because a byte value must be in the [0, 255] interval.

Observed in production when parsing PDFs with ASCII85-encoded streams that have a partial trailing group.

Fix

Apply & 0xFF bitmask to extract individual bytes before passing to chr(), consistent with the approach used in the main loop fix from #779.

& 0xFF is the standard bitwise idiom for extracting a single byte from a multi-byte integer (equivalent to % 256 but more idiomatic).

Changes

// Before
$decoded .= \chr($tuple >> 24).\chr($tuple >> 16).\chr($tuple >> 8);

// After
$decoded .= \chr(($tuple >> 24) & 0xFF).\chr(($tuple >> 16) & 0xFF).\chr(($tuple >> 8) & 0xFF);

Same pattern applied to case 3 and case 2.

[k00ni]

@Ciki Thank you for the PR.

If I remember correctly, the changes in #779 where suggested somewhere to fix PHP 8.5 related deprecations. I have limited knowledge in this area so I had to check your information. The following two pages describe bit-wise operations quite a bit:

1. https://medium.com/android-news/java-when-to-use-n-8-0xff-and-when-to-use-byte-n-8-2efd82ae7dd7
2. https://oscarliang.com/what-s-the-use-of-and-0xff-in-programming-c-plus-p/

Code looks good. Could you provide one of the PDFs which triggered these so we can use it in our test suite?

I will keep this open for a few days in case someone else wants to comment. Or do you need it merged right away?