harden: resolve the swap approval screen's token scale, or refuse to format (closes #340)

tokenInfo() in src/shared/uniswap.js returned decimals: 18 for any token absent from the bundled token list, the same guessed scale that issue 306 removed from the ERC-20 amount line of the same screen. A 1,000-token swap of a 6-decimal token was therefore stated as 0.000000001, a wrong number rather than an imprecise one, and every newly listed token reached it. The swap's Amount and Min. received lines now resolve the scale through resolveTokenDecimals() -- the bundled list, then the tokens the user tracks, then the decimals the block explorer reported -- and where none of those answers they render unknownDecimalsAmount(), the base-unit integer with the scale stated, which is the same refusal the ERC-20 line already makes. No new data source and no network call: the scale comes only from what the wallet already holds, so the screen still makes no request before showing what is being signed. uniswap.decode() takes those sources as a third argument, supplied by decodeCalldata() from state alongside the ones the ERC-20 path already used. An unbounded permit needs no scale to describe and is still shown as Unlimited. README.md records the rule as a Display Consistency exception.

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.