harden: resolve or refuse the swap token scale instead of guessing 18 (closes #340)

tokenInfo() returned decimals 18 for any token absent from the bundled list, so the swap approval line rendered a real 1000.00 of a 6-decimal token as 0.000000000001. The scale is now resolved from what the wallet already holds (bundled list, tracked tokens, explorer-reported decimals) or refused outright, matching the rule set for the ERC-20 path in #306. A refusal reuses unknownDecimalsAmount(), so it reads as "base units (decimals unknown)" with no decimal point and no symbol, and the same string propagates to rawValue so no downstream screen can render a figure the approval screen refused. No new network call on the approval path. Verified green on all three CI contexts: check, e2e-chrome, e2e-firefox.

src/shared/approvalAmount.js

@@ -14,6 +14,10 @@
 // them answers, unknownDecimalsAmount() renders the base-unit integer with the
 // unknown scale stated, and no formatUnits() call is reached at all.
 //
+// The Uniswap decoder's Amount and Min. received lines land on this same
+// screen and use these same two functions, so there is one way of resolving a
+// scale and one way of saying there is none.
+//
 // This is the display counterpart to transferAmount.js, which takes the same
 // stance on the wallet's own send path: an amount whose scale is unknown or
 // disputed is refused rather than guessed at.