Fix error from personal key validation unexpected characters

[aduth]

🛠 Summary of changes

Fixes an error which occurs when the user enters an invalid (non-alphanumeric) character in the personal key step of the identity verification flow.

The base32-decode library used in @18f/identity-personal-key-input throws an error when encountering an unexpected character. Rather than letting these errors throw unhandled, catch them and treat them as equivalent to an invalid entry.

NewRelic: https://onenr.io/0bRmopb8BQy

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• rspec './spec/features/idv/steps/confirmation_step_spec.rb[1:1:2:2]' passes (fails on main with changes to spec)

[aduth]

Hm, based on the error in NewRelic seemingly not specifying the character (and there are errors which do), I wonder if this is caused by the user using whitespace as delimiters for code fragments. It seems like we should be tolerant to that, similar to how we're tolerant to the optional use of dashes?

e.g. 1234-ABCD-5678-EFGH and 1234ABCD5678EFGH and 1234 ABCD 5678 EFGH would all be considered valid.

[aduth]

Hm, based on the error in NewRelic seemingly not specifying the character (and there are errors which do), I wonder if this is caused by the user using whitespace as delimiters for code fragments. It seems like we should be tolerant to that, similar to how we're tolerant to the optional use of dashes?

e.g. 1234-ABCD-5678-EFGH and 1234ABCD5678EFGH and 1234 ABCD 5678 EFGH would all be considered valid.

This is a bit trickier to implement than I'd expected, due to a combination of (a) the field being limited to 16 characters and (b) the Cleave.js formatting allowing a single delimiter (not either spaces or dashes). We probably need to prevent the user from entering certain characters, but this too isn't straightforward with Cleave.js (related issue).

I confirmed that this error--while noisy in NewRelic--does not appear to have an impact on the user-facing validation, and invalid characters are treated as equivalent to an invalid submission (error message appears as expected). So without that urgency, I'll plan to revert this back to draft to try to come up with a more robust handling of characters.

[aduth]

I'll plan to revert this back to draft to try to come up with a more robust handling of characters.

On second thought, I'm not going to spend much effort enhancing this behavior if the plan is to remove the confirmation modal altogether (started in #6821). The changes here should silence the errors in NewRelic at least.

[zachmargolis]

LGTM