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

src/shared/txValidation.js

@@ -1,4 +1,5 @@
-// Balance arithmetic for the Send and transaction confirmation screens.
+// The amount check and balance arithmetic for the Send and transaction
+// confirmation screens.
 //
 // Pure: no DOM, no network, no state. Everything is exact integer math on
 // 18-decimal fixed point (wei for ETH), so it can be unit tested directly
@@ -20,7 +21,7 @@ const FEE_KNOWN = "known";
 const FEE_UNAVAILABLE = "unavailable";
 
 const CODES = {
-    // The amount is not a non-negative number we can do exact arithmetic on.
+    // The amount is one isValidAmount() refuses.
     AMOUNT_INVALID: "amount-invalid",
     // ERC-20: the token amount exceeds the token balance.
     INSUFFICIENT_TOKEN: "insufficient-token",
@@ -87,6 +88,27 @@ function toFixedPoint(value) {
     }
 }
 
+// Whether `amount` can be sent: a number above zero, written as digits with
+// at most one decimal point ("0.5", "12", ".5"), with nothing but zeros after
+// the token's last decimal place, `tokenDecimals`, and nothing but zeros after
+// the 18th, the places the arithmetic here works in, which are ETH's. ETH, and
+// a token whose decimal places are unknown, pass null and are held to the 18
+// (the confirmation screen refuses to send such a token anyway). Zeros past
+// those places are accepted because parseUnits() drops them here and again
+// when the transfer is encoded, so "1.0000000" of a 6-place token is exactly
+// 1 everywhere. Refuses "1e-3", "1abc", "0" and "-1". The Send screen checks
+// it before the confirmation screen opens, and validateTransfer() checks it
+// again there.
+function isValidAmount(amount, tokenDecimals = null) {
+    if (typeof amount !== "string") return false;
+    const places = Math.min(tokenDecimals ?? SCALE_DECIMALS, SCALE_DECIMALS);
+    try {
+        return parseUnits(amount.trim(), places) > 0n;
+    } catch {
+        return false;
+    }
+}
+
 // The most ETH a send can carry: the exact balance minus the fee reserve from
 // feeReserveWei(), as a decimal string, so validateTransfer() passes it with
 // exactly that reserve left behind. `ethBalance` is the exact decimal string
@@ -112,9 +134,11 @@ function maxTokenAmount(tokenBalance) {
 // Validate a pending transfer against the balances that must cover it.
 //
 //   isErc20      — token transfer rather than a native ETH transfer
-//   amount       — human decimal string being sent, non-negative. Anything
-//                  else, a negative value included, is an unusable amount
+//   amount       — human decimal string being sent. One isValidAmount()
+//                  refuses, a negative value included, is an unusable amount
 //                  rather than an amount that passes every comparison.
+//   tokenDecimals — ERC-20: the token's decimal places, or null when they
+//                  are unknown. Passed to isValidAmount().
 //   ethBalance   — human decimal string, the sender's ETH balance
 //   tokenBalance — human decimal string, the sender's token balance
 //   feeStatus    — FEE_PENDING, FEE_KNOWN or FEE_UNAVAILABLE. Anything else
@@ -128,6 +152,7 @@ function maxTokenAmount(tokenBalance) {
 function validateTransfer({
     isErc20 = false,
     amount,
+    tokenDecimals = null,
     ethBalance,
     tokenBalance,
     feeStatus = FEE_PENDING,
@@ -135,17 +160,17 @@ function validateTransfer({
 } = {}) {
     const codes = [];
 
-    const amountFp = toFixedPoint(amount);
-    const ethFp = toFixedPoint(ethBalance) ?? 0n;
-
-    // A negative amount parses to a valid bigint, so every comparison below
-    // is trivially false and the send clears the screen — then dies at encode
-    // time in parseEther(). Unusable, on the same footing as a malformed fee.
-    if (amountFp === null || amountFp < 0n) {
+    // An amount refused here never reaches the comparisons below: a negative
+    // one would pass every one of them, then die at encode time in
+    // parseEther().
+    if (!isValidAmount(amount, isErc20 ? tokenDecimals : null)) {
         codes.push(CODES.AMOUNT_INVALID);
         return { canSend: false, codes };
     }
 
+    const amountFp = toFixedPoint(amount);
+    const ethFp = toFixedPoint(ethBalance) ?? 0n;
+
     // Fail closed. Anything that is not a usable fee under a recognised
     // status — a malformed feeWei, or a status this module does not know —
     // is an unavailable estimate, never a fee of zero. Every such input errs
@@ -195,6 +220,7 @@ module.exports = {
     SCALE_DECIMALS,
     feeReserveWei,
     feeEstimateWei,
+    isValidAmount,
     maxEthAmount,
     maxTokenAmount,
     toFixedPoint,