fix: Send refuses every amount the confirmation screen would refuse (closes #532)

Send's Review accepted any amount parseFloat() read as above zero, so 1e-3, 1abc and amounts with too many decimal places reached ConfirmTx, which then refused them or failed to estimate the fee.

isValidAmount() in src/shared/txValidation.js is now the one amount check, used by Send's Review and Max and by validateTransfer() for ConfirmTx: plain digits with at most one decimal point, above zero, nothing but zeros past the token's places. Zeros past those places are accepted, since the transfer encodes the amount exactly. Send now reads the token's decimal places before the ENS lookup, because the check needs them.

Judgement call: ConfirmTx now also refuses zero, as Send already did.

Model: opus-5-5

README.md

@@ -1686,7 +1686,13 @@ view would leave a wallet one click from deletion.
 - **Transitions**:
     - "Review" (valid inputs, ENS resolved) → **ConfirmTx**
     - "Review" with an unresolvable ENS name or an invalid amount → flash
-      message, no screen change
+      message, no screen change. An amount is valid when it is a number above
+      zero, written as digits with at most one decimal point, with nothing but
+      zeros after the token's last decimal place. ETH has 18 places, and a token
+      with more, or with an unknown number, is held to 18. Zeros past those
+      places leave the amount unchanged, so `1.0000000` of a 6-place token
+      passes and is sent as exactly 1. ConfirmTx makes the same check before
+      anything can be sent
     - "Back" → previous screen (Home, AddressDetail, or AddressToken)
 
 #### ConfirmTx (`confirm-tx`)