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, and the fee no longer
matched the approval screen's. The ETH balance is now stored exactly, and the
send screen's Current balance and the send-confirm screen's balance, fee,
reserve and insufficient-balance messages go through truncateAmountNeverZero(),
as the approval screen does. Token balances keep their six-decimal value: it is
also what leaves dust off the balance list, and keeps the string within the 18
decimals the balance check reads.

Model: opus-5-5

README.md

@@ -889,11 +889,16 @@ shows as `0.9999`, never rounded up.
 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
+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`), so a fee reads the same there as on the
+approval screen. For this the ETH balance is stored exactly. 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