fix: every balance is cut to four decimals (closes #757)

The balance lists and Home's ETH line rounded with toFixed(4), so 0.99996
ETH read 1.0000 there and 0.9999 on Send. Send's current balance and
ConfirmTx's balance line kept the nonzero floor, so 0.00004 USDC read
0.0000 in the lists and 0.00004 on Send. All four now cut the stored
decimal string with truncateAmount(), as the history rows do.
balanceLine() takes the stored balance string instead of a parsed number,
and escapes the quantity cell. The amounts, fees and allowances a screen
asks the user to approve keep the floor of truncateAmountNeverZero().

Model: opus-5-5

README.md

@@ -1191,15 +1191,23 @@ These helpers write one kind of value on every screen that shows it:
 
 Most screens show token and ETH amounts with four decimal places. History rows
 cut amounts to four decimals and never round up (`truncateAmount()` in
-`src/shared/amountDisplay.js`). The balance lists and Home's ETH balance round
-to four places. The screens that state what is being authorized cut as the
-history does, and extend an amount below 0.0001 to its first nonzero digit
+`src/shared/amountDisplay.js`). These balances are cut the same way:
+
+- the balance lists;
+- Home's ETH balance;
+- Send's current balance;
+- ConfirmTx's balance line.
+
+So a balance below 0.0001 reads `0.0000` there.
+
+The screens that state what is being authorized cut as the history does, and
+extend an amount below 0.0001 to its first nonzero digit
 (`truncateAmountNeverZero()`). So a nonzero amount never reads as zero there.
 Those screens are:
 
 - TxApproval;
 - SignApproval's Permit warning;
-- ConfirmTx, and Send's current balance;
+- ConfirmTx's amount and network fee;
 - WaitTx, SuccessTx and ErrorTx.
 
 TransactionDetail shows the exact amount and its base units.