feat: rfox improve no rewards address ux

[gomesalexandre]

Description

Does what it says on the box, makes things more obvious for users re: no rewards address:

• The first change which makes the rest possible here is to default to manual address input when we detect both no current rewards address and no wallet runtime/support.
  In this case, we effectively assume that manual address input is the default/only valid flow here. This may not be exactly true in case accounts are loading, but this is a compromise
  to make things work for most cases and reduce regressions risks, at the expense of this one specific case (users can always revert back to wallet account selection).
• Makes the input required if there is no current rune address. This is made possible thanks to the above: the (manual) input form is only conditionally rendered if the conditions above are met.
  This means that native users will not end up there (unless explicitly selecting manual address input, in which case manual input will be required as expected), as they will default to account selection.
  For others (e.g EVM-only wallets), the input will be the default, and since it is required, will render default react-hook-form/browser red required styles.
• Adds button translations for "Select a RUNE address", in case the red errored input state above is not obvious enough

Issue (if applicable)

closes #8487

Risk

High Risk PRs Require 2 approvals

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Low/Medium, RFOX form validation is quite a risky one

Testing

• EVM wallets without a RUNE rewards address yet should default to manual input selection, with errored input styles and "Select RUNE address" copy until a RUNE addy is input
• Native wallets accounts without RUNE rewards address (with accounts already loaded) should default to account selection, and never have the copy mentioned above nor input error since there is no input
  (unless explicitly selecting manual address input, in which case the input validation flow should be just the same as EVM wallets)
• EVM/native wallet accounts with a rewards addy (assuming accounts loaded) should behave the same as develop

Engineering

• ^

Operations

• 🏁 My feature is behind a flag and doesn't require operations testing (yet)

• ^

Screenshots (if applicable)

https://jam.dev/c/2ad3937d-0676-4788-b82b-ce2b39fcfca8

[gomesalexandre]

See onChange() below

[gomesalexandre]

More of a paranoia than anything else.
We will not render the manual field input if currentRuneAddress (disabled account selection will be rendered instead, or a tag for EVM wallets), so we should be safe with required: true but better be safe than sorry by being explicit.

[gomesalexandre]

Reset on empty input

[gomesalexandre]

i.e onBlur, onChange, onSubmit and onTouched, ensuring that the input becomes red if errorred in all those change modes.

[gomesalexandre]

Explicit handling of the required error, since it is not coming from a custom validation rule, but from native react-hook-form's required property above

[gomesalexandre]

Avoids screaming at users with big scary red color for the required case