fix: sign the ERC-20 amount the confirmation screen displayed (closes #305)

The send screen was built from the indexer's decimals while the transfer was
encoded from the contract's decimals() read at signing time, with nothing
comparing them. A token whose scales disagree moved 10^12 times the approved
amount.

The displayed scale is now carried on pendingTx from the same tokenBalances
entry the amount, balance and symbol were rendered from, and both encode sites
use it. transferAmount.js refuses rather than falling back when the two scales
disagree or either is unusable.

Adds the first end-to-end coverage of the popup's own Send -> ConfirmTx ->
Sign & Send path; #btn-confirm-send had never been clicked by any test.

TODO.md

@@ -44,6 +44,27 @@ but the review is broader than any of them.
 
 # Completed Steps
 
+- 2026-08-20: The wallet's own ERC-20 send signs the amount it displayed
+  ([#305](https://git.eeqj.de/sneak/AutistMask/issues/305)). The confirmation
+  screen renders from the block explorer's cached decimals; the transfer was
+  encoded from `decimals()` read off the contract at signing time, and nothing
+  compared the two, so a token whose on-chain scale disagreed — an upgradeable
+  or proxy token, a stale explorer entry, a compromised Blockscout — signed an
+  amount that was never on screen, off by a power of ten per decimal place of
+  disagreement. The scale is now carried forward on the pending transaction from
+  the same balance entry the screen's amount, balance and symbol come from, and
+  the contract's answer is read at signing time only to be compared with it: a
+  disagreement is a refusal naming both numbers, never a preference for either
+  (`src/shared/transferAmount.js`, the `confirmTx` counterpart to
+  `approvalVerify.js`). The gas estimate encodes from the same carried value and
+  no longer reads `decimals()` at all. Nothing in the e2e suite had ever clicked
+  `#btn-confirm-send`, which is how this shipped: the popup's own Send →
+  ConfirmTx → Sign & Send → WaitTx path now runs end to end to a broadcast, with
+  the `transfer()` amount decoded out of the raw signed bytes and asserted
+  against what the screen displayed, and a companion case where the contract
+  starts answering a different scale after the screen was built and nothing
+  reaches the RPC. Reverting only the signing-side comparison turns that second
+  case red and leaves the other 53 green.
 - 2026-08-17: The Settings screen is driven in a browser, and every element id
   the popup looks up is checked statically. Nothing exercised Settings in the
   e2e suite, and jest runs with no DOM, so the densest run of `$("...")` lookups