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

@@ -1065,9 +1065,9 @@ 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. `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
+every nonzero holding of a token it admits, 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.