isBase64: reject strings whose length is 1 mod 4 when padding is off

[HrachShah]

Bug: With padding: false, isBase64() accepted any string of valid base64 characters regardless of length, including impossible ones like 'A' (1 char), 'AAAAA' (5 chars), or 'AAAAAAAAA' (9 chars).

Why: A base64 string's length is always 0, 2, 3, 4, 6, 7, 8, 10, 11, 12, 14, ..., i.e. (length % 4) in {0, 2, 3}. A length of the form 4k+1 cannot be produced by any base64 encoding of any byte string. The padding-enabled path already enforced length % 4 == 0; the padding-disabled path was missing the analogous check.

Fix: After the character-class regex matches, also require length % 4 != 1 when padding is off.

Tests: New it() with both standard and urlSafe variants asserts that 1-mod-4 strings are rejected and 0/2/3-mod-4 strings (taken from real base64 encodings) are still accepted. Full suite: 319 passing (was 318).

[tux-tn]

Thank you for your PR, I added some suggestions to your changes.
Also, could you either move the isHash change into a separate PR or update this PR’s title and description to document why it is included? It is currently outside the stated Base64 scope.

[tux-tn]

This line is failing eslint validation also this helper is used only one time.

Suggested change

const validUnpaddedLength = (n) => n % 4 !== 1;

[tux-tn]

The single-use validUnpaddedLength helper and nested branching are unnecessary. Also the remainder of str.length % 4 is computed two times.
It can be easily replaced by a single check:

Suggested change

	if (options.padding) {
	if (str.length % 4 !== 0) return false;
	} else if (!validUnpaddedLength(str.length)) {
	return false;
	}
	const remainder = str.length % 4;
	const isValidLength = options.padding ? remainder === 0 : remainder !== 1;
	if (!isValidLength) return false;