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.

README.md

@@ -883,6 +883,25 @@ transaction detail view is the authoritative record and already shows exact
 precision. The 4-decimal rule is unchanged everywhere else, including for
 amounts at or above the floor on the approval screens.
 
+The floor applies only where the token's scale is known. Where it is not, the
+approval screen states base units instead of a quantity — see Unknown token
+scale below — and no truncation happens at all.
+
+**Specific Exception — unknown token scale:** Calldata carries base units and no
+scale, so every amount on the dApp approval screen needs the token's `decimals`.
+It is resolved from the bundled token list, then from the tokens the user
+tracks, then from what the block explorer reported for the contract
+(`resolveTokenDecimals()` in `src/shared/approvalAmount.js`). Where none of them
+answers, the amount is not formatted: the line reads
+`5000000000 base units (decimals unknown)`. A guessed scale is not an
+approximation but a different number — 1,000 units of a 6-decimal token
+formatted at 18 decimals reads `0.000000001` — on the screen whose only job is
+to state what is being authorized. Both amount paths of that screen take this
+rule: the ERC-20 `transfer`/`approve` line (`src/popup/views/approval.js`) and
+the swap's `Amount` and `Min. received` lines (`src/shared/uniswap.js`). An
+unbounded allowance or permit needs no scale to describe and is still shown as
+`Unlimited`.
+
 #### Partial USD totals
 
 Prices are fetched for the top 25 tokens only, so an address can hold assets the