fix: show balances and fees below 0.000001 ETH as nonzero on the send screens (closes #343)

The stored ETH balance and the send-confirm screen's fee were each cut to six
decimal places, so a value below 0.000001 read as 0.0. The ETH balance is now
stored exactly, and the send and send-confirm screens' balances, reserve and
insufficient-balance messages go through truncateAmountNeverZero(). Both the
send-confirm and approval screens render the fee through formatFee(), which
prices the exact fee in USD, so the same fee reads the same on both. Token
balances keep their six-decimal value: it also leaves dust off the balance
list, and keeps the string within the 18 decimals the balance check reads.

Model: opus-5-5

README.md

@@ -892,12 +892,20 @@ shows is a V4 exact-in `amountIn` of zero.
 The rule and its exception live in `src/shared/amountDisplay.js` as
 `truncateAmount()` and `truncateAmountNeverZero()`. Everything the approval and
 confirmation screens display goes through the floored one — the ERC-20 amount,
-the ETH value and max fee (`src/popup/views/approval.js`), and the swap's
-`Amount` and `Min. received` lines (`src/shared/uniswap.js`). The history and
-balance lists (`src/shared/transactions.js`) use the unfloored one: the
-transaction detail view is the authoritative record and already shows exact
-precision. The 4-decimal rule is unchanged everywhere else, including for
-amounts at or above the floor on the approval screens.
+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. The ETH balance is stored exactly, so a balance below the floor
+reaches these screens as it is. A token balance is stored to six decimal places,
+and a holding below 0.000001 is not listed at all. The history and balance lists
+(`src/shared/transactions.js`) use the unfloored one: the transaction detail
+view is the authoritative record and already shows exact precision. 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