Fix return of cred protect value for resident ed25519 keys

The cred protect value was not masked correctly when reading it from a
resident key. This did no harm for ec256, as the stored algorithm ID
happens to be zero wich does not invalidate the cred protect value.

For eddsa, where the stored algorithm ID is 1, the cred protect value
left the range of 1-3 and was forcibly mapped back to the default value
(1). I.e., all existing resident ed25519 keys should have stored the
correct cred protect values already. With this fix applied, the correct
values will be returned instead of a fixed value of 1.

fido2/ctap.c

@@ -1494,7 +1494,7 @@ uint8_t ctap_cred_rk(CborEncoder * encoder, int rk_ind, int rk_count)
     CTAP_residentKey rk;
     ctap_load_rk(rk_ind, &rk);
 
-    uint32_t cred_protect = read_metadata_from_masked_credential(&rk.id);
+    uint32_t cred_protect = read_cred_protect_from_masked_credential(&rk.id);
     if ( cred_protect == 0 || cred_protect > 3 )
     {
         // Take default value of userVerificationOptional