Describe the bug

On gh version 2.5.2, I thought gh auth login had failed due to the following output:

✓ Authentication complete.
- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
HTTP 422: Validation Failed (https://api.github.com/user/keys)
key is already in use

It's true that the SSH key I nominated is already in use on GitHub - it's in use by me, on the account I was giving the gh CLI access to. Based on this output, I initially thought the client registration had failed.

After checking https://docs.github.com/en/authentication/troubleshooting-ssh/error-key-already-in-use I decided to proceed as if the CLI registration had worked, and sure enough it had.

Searching past issues brought me to #4792, which indicates that simply suppressing the error isn't the right thing to do - instead, the client either needs to only suppress it when the key is in use by the account the CLI is being registered to, or else the output needs to be customised to indicate that registering the key is expected to fail if the key was previously uploaded.

Steps to reproduce the behavior

1. Run gh auth login and select an SSH key that is already registered with the account
2. Get the above error, even though the key will work correctly

Expected vs actual behavior

Actual behaviour is described above.

I think there are a couple of ways that the handling of already registered keys could be improved:

1. Given the CLI app is granted full permission over the user's registered SSH keys, it could presumably list the already registered ones first and only attempt to register a new key if it wasn't already registered. Then the error would only occur if the key was registered on a different account (or you uploaded it via the web browser while also attempting to register the CLI app, which would be an odd thing to do)
2. Customise the error message when this step fails to say something like "key already in use (Note: this error is expected if this SSH key was already registered on your account)"

I'm not sure how hard the first option would be to implement, so the second option could be a good interim workaround if checking isn't easy.