docs: fix stale zero claim, list what decoded approval amount lines read (closes #369)

The README said a genuine zero always renders `0.0000`, beside a
`Min. received` example, though a zero minimum there now reads
`None (no minimum guaranteed)`. It now says the amount rule renders a
zero as `0.0000` and that two swap lines say a zero in words instead:
`Min. received` for a zero minimum, and `Amount` when it shows a V4
exact-in `amountIn` of zero.

A new list says what the decoded ERC-20 and swap amount lines on the
transaction approval screen can read, including that a zero
`BALANCE_CHECK_ERC20` `minBalance` now reads the no-minimum wording.
The token permission warning on the signature screen is left to the
SignApproval section.

Model: opus-5-5

README.md

@@ -882,9 +882,12 @@ On those screens, when the truncated string would contain no digit from 1 to 9
 and the value does, the amount is extended to its first significant digit
 instead: `0.000000000000000001 DAI`, not `0.0000 DAI`. The test is on the whole
 truncated string, integer part included, so `1.00005` still shows as `1.0000` —
-the exception only fires where the entire displayed figure would read as zero. A
+the exception only fires where the entire displayed figure would read as zero.
-genuine zero still renders `0.0000`, and truncation stays truncation: `0.99999`
+Truncation stays truncation: `0.99999` shows as `0.9999`, never rounded up. The
-shows as `0.9999`, never rounded up.
+rule still renders a genuine zero as `0.0000`. Two lines of a swap say a zero in
+words instead: `Min. received` reads `None (no minimum guaranteed)` for a zero
+minimum, and `Amount` reads `All available (V4 open delta)` when the amount it
+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
@@ -937,6 +940,41 @@ and compare against. Reading the stored field directly instead answers `null`
 for a bundled or tracked token the explorer merely omitted, which is not a
 refusal the wallet has any reason to make.
 
+**Decoded amount lines on the transaction approval screen:** the `Amount` line
+of a decoded ERC-20 call, and the `Amount` and `Min. received` lines of a
+decoded swap (see TxApproval below), do not always read as a number. They can
+read:
+
+- A formatted quantity, e.g. `17.1900 USDT`, when the token's scale is known:
+  truncated to four decimals, with the floor and the zero cases described above.
+- `<amount> base units (decimals unknown)` when the scale is unknown: the
+  base-unit integer, rather than a figure at a guessed scale (see Unknown token
+  scale above).
+- `Unlimited`: on the ERC-20 `Amount` line, an `approve` of the `uint256`
+  maximum, an unbounded allowance. On the swap's `Amount` line, any amount at or
+  above the `uint160` maximum, whichever step set the line: a `PERMIT2_PERMIT`
+  amount at that maximum, which is an unbounded permit, or a V2 or V3 exact-in
+  or `WRAP_ETH` amount that large, which is not an allowance. The router's
+  whole-balance value, `CONTRACT_BALANCE` (`2^255`), is one such amount.
+- `All available (V4 open delta)`: the swap's `Amount` line, when the amount it
+  shows is a V4 exact-in `amountIn` of zero. V4 reads that zero as "use the
+  whole open delta", so the calldata states no quantity. The line shows the
+  amount of one step that names an input token or amount: the last
+  `PERMIT2_PERMIT` step if there is one, otherwise the first V2 or V3 exact-in,
+  `WRAP_ETH` or V4 swap step, a V4 swap step giving the `amountIn` of its first
+  readable exact-in action.
+- `None (no minimum guaranteed)`: the swap's `Min. received` line, when the
+  minimum it shows is zero, whether a V2, V3 or V4 swap's minimum or a
+  `BALANCE_CHECK_ERC20` step's `minBalance`. Before
+  [#359](https://git.eeqj.de/sneak/AutistMask/issues/359), a zero `minBalance`
+  read `0.0000` when the token's scale was known.
+
+The swap's `Token In` and `Token Out` lines name a currency, not an amount; each
+reads `Unknown (not named in the calldata)` when the decoder found no token for
+that side. The token permission warning on the signature screen has its own
+amount wording, including `Unknown`; the SignApproval section below describes
+it.
+
 #### Partial USD totals
 
 Prices are fetched for the top 25 tokens only, so an address can hold assets the

TODO.md

@@ -173,6 +173,20 @@ but the review is broader than any of them.
   standalone storage entry, never part of the versioned `autistmask` profile, so
   the state schema is untouched and no existing profile is affected.
 
+- 2026-09-21: `README.md` no longer says a genuine zero always renders `0.0000`
+  ([#369](https://git.eeqj.de/sneak/AutistMask/issues/369)). The amount rule
+  still renders one as `0.0000`, but two swap lines say a zero in words instead:
+  `Min. received` reads `None (no minimum guaranteed)` for a zero minimum, and
+  `Amount` reads `All available (V4 open delta)` when the amount it shows is a
+  V4 exact-in `amountIn` of zero. A new list says what the decoded ERC-20 and
+  swap amount lines on the transaction approval screen can read: a formatted
+  quantity, base units with decimals unknown, `Unlimited`,
+  `All available (V4 open delta)` and `None (no minimum guaranteed)`, which a
+  zero `minBalance` on a `BALANCE_CHECK_ERC20` step now reads instead of
+  `0.0000` at a known scale. The README also names
+  `Unknown (not named in the calldata)` on the swap's token lines, and points to
+  SignApproval for the token permission warning's own wording. Docs only.
+
 - 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
   common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
   wallet list was the reported case: the address shared one row with the