fix: every screen cuts amounts the same way (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, and 0.00004 USDC read 0.0000.
They now show the stored decimal string through truncateAmountNeverZero(),
as Send and the approval screens do. History rows take the same floor.
truncateAmount() is no longer exported. balanceLine() now takes the stored
balance string instead of a parsed number.

Model: opus-5-5

README.md

@@ -1187,20 +1187,17 @@ These helpers write one kind of value on every screen that shows it:
   times;
 - `renderAddressHtml()` in the same file: most addresses.
 
-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
-(`truncateAmountNeverZero()`). So a nonzero amount never reads as zero there.
-Those screens are:
+Every screen shows token and ETH amounts the same way, through
+`truncateAmountNeverZero()` in `src/shared/amountDisplay.js`:
 
-- TxApproval;
-- SignApproval's Permit warning;
-- ConfirmTx, and Send's current balance;
-- WaitTx, SuccessTx and ErrorTx.
+- an amount is cut to four decimal places, never rounded, so 0.99996 reads
+  `0.9999`;
+- an amount below 0.0001 is shown to its first nonzero digit, so 0.00004 reads
+  `0.00004`.
 
-TransactionDetail shows the exact amount and its base units.
+So an amount never reads as more than it is, and a nonzero amount never reads as
+zero. TransactionDetail is the one exception: it shows the exact amount and its
+base units.
 
 An amount to send is valid when it is a number above zero, written as digits
 with at most one decimal point. Nothing but zeros may follow the token's last