fix(totp): require a TOTP secret to be the full 20 bytes

[Jaro-c]

decodeSecret enforced no length. Its only size test was len(key) == 0, so any secret that decoded to at least one byte was accepted and used as an HMAC key. secretLen has been declared as 20 three functions away the whole time and nothing compared against it.

Measured on develop at 6396536:

input	decoded	accepted before
MZXW6YTB	5 bytes	yes
AAAAAAAA	5 bytes	yes
MZXW6YTBMZXW6YTB	10 bytes	yes

A 5-byte secret is a 40-bit keyspace, and generateTOTP produced codes from it without complaint.

Enroll always mints secretLen bytes, so nothing this package generates was affected. The exposure is a secret arriving from outside: migrated from another TOTP implementation, pasted by a user, or restored from a store that truncated it.

The trap, because it is what the tests are built around

Short inputs did fail before this, and they failed for the wrong reason. The encoding was selected by len(s)%8 != 0, so a length that is not a multiple of 8 got the padded encoding and was rejected as malformed base32. That reads like a length control and is not one. Every length that is a multiple of 8 took the unpadded branch and decoded cleanly at whatever size it produced.

The four subtests that go red when the old len(key) == 0 check is restored are exactly the multiple-of-8 cases, which is what makes them a test of the length check rather than of the encoding heuristic.

The encoding branch is gone too

That is a consequence of the length check, not a separate decision, and I measured it before removing anything: 20 bytes is exactly four 40-bit base32 groups, so it encodes to 32 characters with no padding and the padded and unpadded forms of a valid secret are byte-identical. The branch could therefore no longer select an encoding for any input the length check would accept. Leaving it would have left a tolerance that tolerates nothing.

The encoded input is also capped before decoding rather than after.

Provenance

Found by a MiniMax-M3 pass over the package. Its conclusion was right and its reproduction was wrong: it offered MY as an accepted one-byte secret, and MY is rejected, by the padding heuristic above. Running its example alone would have closed this as a false positive.

Closes #357