base64ct: decode_in_place rejects non-zero trailing bits like decode - #2459

Encoding::decode checks that the last block round-trips (validate_last_block, added in #680 for #679), so an encoding with non-zero trailing bits is rejected. decode_in_place never got that check:

let mut buf = *b"AB==";
Base64::decode(b"AB==", &mut [0u8; 3])   // Err(InvalidEncoding)
Base64::decode_in_place(&mut buf)        // Ok([0x00]), same as for "AA=="

let mut buf = *b"Mi";                    // the #679 example
Base64Unpadded::decode_in_place(&mut buf) // Ok([0x32]), same as for "Mg"

So decode and decode_in_place disagree on which strings are valid Base64, and with decode_in_place several different strings decode to the same bytes. That is exactly what #679 fixed for decode.

The input buffer is overwritten while decoding, so this PR saves its last block (at most 4 bytes, including padding) first, then runs the same validate_last_block on the result.

Tests in tests/proptests.rs:

• decode_in_place_equiv: a proptest that decode_in_place accepts exactly what decode_vec accepts, with the same output, for Base64 and Base64Unpadded.
• decode_in_place_rejects_trailing_bits: a regression test for "AB==" / "AB", and a check that "AA==" still decodes.

Both fail on master (minimal failing input: "++").

This PR was produced by AI agents (Claude) while fuzzing base64ct against the base64 crate.