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

The stored ETH and token balances and the send-confirm screen's fee were each
cut to six decimal places, and a token holding cut to zero was dropped, so a
value below 0.000001 read as zero. Balances are now stored exactly, whatever
decimals a token declares, and every nonzero token holding is kept; the balance
check reads a token balance to its first 18 places. The balance lists, the
send-screen token selector, the address total and the remove-address warning
leave out a holding below 0.000001 themselves, through isBelowOneMillionth().
The send and send-confirm screens' balances, reserve and insufficient-balance
messages go through truncateAmountNeverZero(). The send-confirm and approval
screens both render the fee through formatFee(), which prices the exact fee in
USD.

Model: opus-5-5

README.md

@@ -892,12 +892,21 @@ 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. 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
@@ -1055,8 +1064,13 @@ list from any other contract address is always dropped, and so is any token
 claiming a symbol that belongs to the native asset and therefore has no
 legitimate contract at all (`"ETH"`). That filter is unconditional — the "Hide
 tokens with fewer than 1,000 holders" setting governs the transaction history
-and the send-screen token selector, not this list. Tracked tokens with a zero
-balance are listed as well while "Show tracked tokens with zero balance" is on.
+and the send-screen token selector, not this list. `fetchTokenBalances()` stores
+every nonzero holding of a token it admits exactly, however small, but a holding
+below 0.000001 is left out of the balance lists, the send-screen token selector,
+the address total and the remove-address warning (`isBelowOneMillionth()` in
+`src/shared/amountDisplay.js`). The Send and confirmation screens show it when
+its token is the one being sent. Tracked tokens with a zero balance are listed
+as well while "Show tracked tokens with zero balance" is on.
 
 #### Stored state and its version