reject 0xFF byte in BASE64DecoderStream conversion table

[arib06]

BASE64DecoderStream fills a 256-entry lookup table that maps each input byte to its base64 value or to -1 for anything outside the alphabet, but the init loop stops at index 254 and leaves the last slot at its default of 0. A 0xFF byte therefore resolves to 0 rather than -1, so getByte treats it as the base64 character A and feeds it into the decoder instead of skipping it the way it skips every other non-alphabet byte. The encoded bytes come straight from untrusted message content, so an attacker can drop a 0xFF into an otherwise valid base64 body part and shift the four-character grouping, which either corrupts the decoded output or raises a DecodingException on input that a conformant decoder accepts. I noticed it while comparing decoder output against java.util.Base64, which ignores the same byte and decodes cleanly. Extending the loop to cover the whole table maps 0xFF to -1 so it is skipped like any other stray byte. The regression test decodes a stream with an injected 0xFF and checks the result matches both the clean stream and the JDK MIME decoder.