[FlorianFranzen]

A malformed PIN of the right length (for example eight 0xFF bytes) was rejected by VERIFY as a format error without touching the retry counter. It is now handed to the verification: it can never match the stored PIN, so it burns a retry exactly like a wrong PIN does on a YubiKey. Clients (yubikey.rs, ykman) exhaust the retry counter before RESET exactly this way.

For that reasoning to hold, every stored PIN has to be well formed. CHANGE REFERENCE DATA already validates new PINs; RESET RETRY COUNTER did not, it stored the raw bytes. The second commit makes it validate the new PIN the same way, so a malformed PIN can no longer be stored by any path, and the asymmetry (VERIFY accepts any 8 bytes, the setters do not) is documented in a comment.

Tested in command_response.ron: two malformed verifications report 2 and 1 remaining, the correct PIN still verifies and resets the counter; a RESET RETRY COUNTER with a malformed new PIN is rejected with IncorrectDataParameter.

[FlorianFranzen]

Revised the second commit after testing the branch against the host tools: the new PIN of RESET RETRY COUNTER was validated before the PUK was compared, which answered 6A80 to the all-FF PUK and all-FF new PIN that ykman's reset (and yubikey.rs users) send to block the PUK, where a YubiKey answers the retry counter. The PUK is now checked first and the new PIN only validated once it matched, so a wrong PUK burns a retry whatever the new PIN looks like; a test for that sequence is added.