decodeCalldata resolved an ERC-20 amount's scale from the 512-entry bundled
token list alone and fell back to 18 decimals for everything else. Most tokens
are outside that list, including anything the user added by contract address, so
a transfer of 5000000000 units of a 6-decimal token - 5,000 tokens - was drawn as
"Amount 0.0000". A user who reads zero confirms, and loses the balance or grants
the allowance.
The new src/shared/approvalAmount.js resolves decimals from the bundled list,
then state.trackedTokens, then the decimals the block explorer already reported
in addr.tokenBalances, accepting only a real uint8 from any of them and refusing
a scale the explorer's own entries disagree about.
Where no source knows the scale the amount is not formatted at all: the line
reads "5000000000 base units (decimals unknown)". A formatted number computed
from a guessed scale is the defect itself, and for a token with fewer decimals
than the guess it is wrong in the direction that reads as zero. approve is
covered alongside transfer; an unbounded allowance still reads "Unlimited",
which needs no scale. The same string is carried to the status screens, so no
formatted figure reappears downstream.
Verified failing first: restoring only the old lookup fails 6 of the 15 new
tests, with the unknown-decimals transfer case receiving exactly "0.0000".
