fix: base64_decode may consume invalid fourth symbol without rejecting

[mbtools]

base64_decode did not reject an invalid fourth Base64 character in a 4-character sequence. That let decoding continue and mix -1 into the output byte instead of stopping, so malformed input could yield wrong bytes instead of a clean abort.

Bug

For c1, c2, and c3, the code already breaks when the lookup is -1. After reading c4, there was no equivalent check. An invalid fourth symbol set c4 to -1, but the code still ran o |= c4, corrupting the computed byte and accepting input that should be invalid.

Fix

After resolving c4 from the input, add if (c4 == -1) break; so invalid fourth symbols match the behavior for the other symbols and decoding stops without emitting a bad byte.

Severity

Medium — Incorrect bytes from bad Base64 can affect correctness of anything that depends on this decoder (e.g. salt/hash parsing). Risk is mainly when input is untrusted or malformed; aligned with treating strict decoding as important in a crypto-related path.

[mbtools]

There are fairly limited tests in this repo. Let me know if you want me to add some for decodeBase64.