fix: the wallet's own send shows its amount to four decimal places (closes #522)

ConfirmTx and the wait, success and error screens printed the text from
Send's amount field as typed or as Max filled it in: `0.5 ETH`, or
`1.234147890123456789 ETH` after Max, where TxApproval shows a site's send
as `0.5000 ETH`. ConfirmTx now shows the amount through
truncateAmountNeverZero(), as TxApproval does, and hands the status screens
a copy carrying that text. The transaction is still signed for the exact
amount, which stays on the pending transaction, and the USD value is priced
from it. A saved confirmation screen whose amount is not text is no longer
redrawn, since the amount is now split.

Model: opus-5-5

README.md

@@ -1082,19 +1082,21 @@ The rule and its exception live in `src/shared/amountDisplay.js` as
 confirmation screens display goes through the floored one — the ERC-20 amount,
 the ETH value and max fee (`src/popup/views/approval.js`), the swap's `Amount`
 and `Min. received` lines (`src/shared/uniswap.js`), the Send screen's
-`Current balance` (`src/popup/views/send.js`), and the balance and network fee
-on the confirmation screen for the wallet's own send
-(`src/popup/views/confirmTx.js`). Both screens render a network fee through
-`formatFee()` in `src/popup/views/helpers.js`, which prices the exact fee in USD
-rather than its truncated figure, so the same fee reads the same on both, USD
-value included. Balances are stored exactly (`src/shared/balances.js`), whatever
-decimals a token declares, so a balance below the floor reaches these screens as
-it is. The history list (`src/shared/transactions.js`) uses the unfloored one:
-the transaction detail view is the authoritative record and already shows exact
-precision. The balance lists use neither: they round to four places with
-`toFixed(4)` (`balanceLine()` in `src/popup/views/helpers.js`). The 4-decimal
-rule is unchanged everywhere else, including for amounts at or above the floor
-on the approval screens.
+`Current balance` (`src/popup/views/send.js`), and the amount, balance and
+network fee on the confirmation screen for the wallet's own send
+(`src/popup/views/confirmTx.js`), which hands the wait, success and error
+screens the amount as it showed it. The transaction is still signed for the
+exact amount, and its USD value is priced from it. Both screens render a network
+fee through `formatFee()` in `src/popup/views/helpers.js`, which prices the
+exact fee in USD rather than its truncated figure, so the same fee reads the
+same on both, USD value included. Balances are stored exactly
+(`src/shared/balances.js`), whatever decimals a token declares, so a balance
+below the floor reaches these screens as it is. The history list
+(`src/shared/transactions.js`) uses the unfloored one: the transaction detail
+view is the authoritative record and already shows exact precision. The balance
+lists use neither: they round to four places with `toFixed(4)` (`balanceLine()`
+in `src/popup/views/helpers.js`). The 4-decimal rule is unchanged everywhere
+else, including for amounts at or above the floor on the approval screens.
 
 The floor applies only where the token's scale is known. Where it is not, the
 approval screen states base units instead of a quantity — see Unknown token
@@ -1757,7 +1759,9 @@ view would leave a wallet one click from deletion.
     - Token contract: full address + etherscan link (ERC-20 only)
     - From: blockie + color dot + full address + etherscan link + wallet title
     - To: blockie + color dot + full address + etherscan link + ENS name
-    - Amount: value + symbol (USD in parentheses). An ETH amount Send's "Max"
+    - Amount: value + symbol (USD in parentheses), the value to four decimal
+      places with the nonzero floor, as on TxApproval (see Display Consistency),
+      however many places Send's amount field held. An ETH amount Send's "Max"
       filled in is worked out again from this screen's own fee estimate when it
       arrives, as the balance minus the reserve, and the transaction is signed
       with that estimate's fee fields, so a fee fetched again at signing cannot