Change Details

This fixes an issue I identified in [ENG-8044](https://linear.app/comm/issue/ENG-8044/cant-log-in-as-commeth-to-staging-identity), which is that we send ETH accounts that have been reserved with the primary keyserver to the registration flow. These accounts should not need to go through the registration flow; rather, they should be able to transparently login via the reserved usernames workflow. Note that after this diff, the login will still fail. [ENG-4033](https://linear.app/comm/issue/ENG-4033/update-clients-to-try-new-registration-after-failed-login-due-to) tracks updating the logic here (and in `ExistingEthereumAccount`) to try to register the account via the reserved usernames workflow (rather than a simple login). I considered factoring this logic out, since both `ConnectEthereum` and `FullscreenSIWEPanel` need to check this. But in ENG-4033 we'll probably need to refactor that check anyways, since we'll want to behave differently in the case of a reserved username versus a fully-registered account. Would normally put @varun on this, but as he's out I figured @inka would be a good reviewer.

This fixes an issue I identified in [ENG-8044](https://linear.app/comm/issue/ENG-8044/cant-log-in-as-commeth-to-staging-identity), which is that we send ETH accounts that have been reserved with the primary keyserver to the registration flow. These accounts should not need to go through the registration flow; rather, they should be able to transparently login via the reserved usernames workflow. The code change was inspired by the equivalent logic in `ConnectEthereum` [here](https://github.com/CommE2E/comm/blob/57d1352c21c1e53989ab3b3759c9555488b99b61/native/account/registration/connect-ethereum.react.js#L159). Note that after this diff, the login will still fail. [ENG-4033](https://linear.app/comm/issue/ENG-4033/update-clients-to-try-new-registration-after-failed-login-due-to) tracks updating the logic here (and in `ExistingEthereumAccount`) to try to register the account via the reserved usernames workflow (rather than a simple login). I considered factoring this logic out, since both `ConnectEthereum` and `FullscreenSIWEPanel` need to check this. But in ENG-4033 we'll probably need to refactor that check anyways, since we'll want to behave differently in the case of a reserved username versus a fully-registered account. Would normally put @varun on this, but as he's out I figured @inka would be a good reviewer.

This fixes an issue I identified in [ENG-8044](https://linear.app/comm/issue/ENG-8044/cant-log-in-as-commeth-to-staging-identity), which is that we send ETH accounts that have been reserved with the primary keyserver to the registration flow. These accounts should not need to go through the registration flow; rather, they should be able to transparently login via the reserved usernames workflow. The code change was inspired by the equivalent logic in `ConnectEthereum` [here](https://github.com/CommE2E/comm/blob/57d1352c21c1e53989ab3b3759c9555488b99b61/native/account/registration/connect-ethereum.react.js#L159). Note that after this diff, the login will still fail. [ENG-4033](https://linear.app/comm/issue/ENG-4033/update-clients-to-try-new-registration-after-failed-login-due-to) tracks updating the logic here (and in `ExistingEthereumAccount`) to try to register the account via the reserved usernames workflow (rather than a simple login). I considered factoring this logic out, since both `ConnectEthereum` and `FullscreenSIWEPanel` need to check this. But in ENG-4033 we'll probably need to refactor that check anyways, since we'll want to behave differently in the case of a reserved username versus a fully-registered account. Would normally put @varun on this, but as he's out I figured @inka would be a good reviewer.