fix: only a permit whose amount is the Amount figure names Token In (closes #370)

A PERMIT2_PERMIT named Token In whether or not its amount stood as the
Amount figure, so the approval screen could show a permit's token, or an
allowance, where the swap's own input belonged.

Now only a permit whose amount stands names Token In. Every other
permit, before the swap steps or after them, leaves Token In and Amount
as they read with no permit and gets three lines of its own: Permit2
allowance, Allowance token and Allowance spender. A V3 swap step's
tokens are checksummed, as every other decoded address is, so a token's
address reads the same on every line. README Transaction Decoding, its
unknown token scale passage and the TxApproval element list match.

Model: opus-5-5

README.md

@@ -1129,13 +1129,15 @@ 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`). The token permission warning on the signature
-screen takes the same rule for its amounts. An unbounded allowance or permit
-needs no scale to describe and is still shown as `Unlimited`. A source's answer
-counts only if it is a whole number from 0 to 80: `decimals()` returns a
-`uint8`, but `formatUnits()` cannot format more than 80 decimal places, so a
-token that reports 81 to 255 is shown as one whose scale nothing knows.
+(`src/popup/views/approval.js`) and the swap's `Amount`, `Min. received`,
+`Moved from the sender` and `Permit2 allowance` lines and the `Paid to` line of
+a move into the router (`src/shared/uniswap.js`). The token permission warning
+on the signature screen takes the same rule for its amounts. An unbounded
+allowance or permit needs no scale to describe and is still shown as
+`Unlimited`. A source's answer counts only if it is a whole number from 0 to 80:
+`decimals()` returns a `uint8`, but `formatUnits()` cannot format more than 80
+decimal places, so a token that reports 81 to 255 is shown as one whose scale
+nothing knows.
 
 The rule holds only if nothing invents a scale UPSTREAM of it. Those three
 sources are read as authoritative, so a value written into one of them cannot be
@@ -2425,10 +2427,11 @@ view would leave a wallet one click from deletion.
       transaction"
     - Decoded action (if calldata is recognized): action name, token details,
       amounts, what each swap step spends that the `Amount` line does not give,
-      what each `PERMIT2_TRANSFER_FROM` moves and where to, steps, deadline, and
-      unless a swap pays only the From address, a `Paid to` line for each other
-      address it pays, or saying that a token stays in the router or who it pays
-      is unknown (see Transaction Decoding)
+      what each `PERMIT2_TRANSFER_FROM` moves and where to, what each
+      `PERMIT2_PERMIT` whose amount is not the `Amount` figure lets its spender
+      take, steps, deadline, and unless a swap pays only the From address, a
+      `Paid to` line for each other address it pays, or saying that a token
+      stays in the router or who it pays is unknown (see Transaction Decoding)
     - From: color dot + full address + etherscan link
     - Contract: color dot + full address + etherscan link, token symbol label if
       known; for a contract creation, the same sentence as on WaitTx
@@ -3217,40 +3220,42 @@ Currently supported:
   added to the total while both are quantities: a V3 exact-in of 600 USDT and a
   V2 exact-in of 400 USDT, both paid by the user, read `1000.0000 USDT`. When
   the decoder does not know a take's amount, the total is not known and there is
-  no `Amount` line. `Token In` is the token of the last `PERMIT2_PERMIT` the
-  decoder reads, when there is one. Its amount, `Unlimited` included, stands as
-  the `Amount` figure in place of the total only in the plain shape of Uniswap's
-  own routes: it is the only `PERMIT2_PERMIT`, its spender is the router, the
-  router may not let it fail, no step before it takes its token or a token the
-  decoder does not know, and the decoder reads every step after it in full.
-  Permit2 then lets the router take no more of the token than that amount, so
-  the permit covers every take of it. A step the decoder does not read in full
-  may raise what Permit2 lets the router take, as a `PERMIT2_PERMIT_BATCH` can:
-  a command the decoder does not read (listed at the end of this section), a
-  step whose input it cannot read, in whole or in part, and a step it fails on.
-  In any other case the line gives the total, as with no permit. When the step
-  that sets the input side spends a token other than the permit's, or one the
-  decoder does not know, its amount gets lines of its own, unless it states no
-  amount and the user pays it none of its input token, and the total has no
-  figure to start from: unless the permit's amount stands there is no `Amount`
-  line, and each take of the permit's token gets lines of its own. Each take the
-  total does not count gives three lines after the `Amount` line (after
-  `Token In` when there is none): one of a token other than `Token In`; one of
-  `Token In` after an amount that is not a quantity (a V4 open delta,
-  `ALREADY_PAID`, which keep their wording on the `Amount` line, or no stated
-  amount, as of a V4 exact-out step); and one whose amount the decoder does not
-  know. When the step that sets the input side states no amount, the user pays
-  it some of its input token, and there is no `Amount` line, that step gets them
-  too whenever another take's lines give a figure, or a `PERMIT2_TRANSFER_FROM`
-  of its token gives one, on the lines below or, into the router, on its
-  `Paid to` line, so that figure cannot read as all that leaves. When it states
-  no amount and the user pays it none of its input token, as when the router
-  pays it, that step takes none of that token from the user's wallet and never
-  gets them, with a permit or without. They come in step order, the step that
-  sets the input side first when it has them: `Moved from the sender`, its
-  amount, worded as the `Amount` line words one, or
-  `Unknown (could not be decoded)` when the decoder does not know it;
-  `Token moved`, giving the token's address as the `Token In` line does; and
+  no `Amount` line. A `PERMIT2_PERMIT` names `Token In` only when its amount,
+  `Unlimited` included, stands as the `Amount` figure in place of the total,
+  which it does only in the plain shape of Uniswap's own routes: it comes before
+  the step that sets the input side, it is the only `PERMIT2_PERMIT` in the
+  transaction, its spender is the router, the router may not let it fail, no
+  step before it takes its token or a token the decoder does not know, and the
+  decoder reads every step after it in full. Permit2 then lets the router take
+  no more of the token than that amount, so the permit covers every take of it.
+  A step the decoder does not read in full may raise what Permit2 lets the
+  router take, as a `PERMIT2_PERMIT_BATCH` can: a command the decoder does not
+  read (listed at the end of this section), a step whose input it cannot read,
+  in whole or in part, and a step it fails on. Every other `PERMIT2_PERMIT`,
+  before the step that sets the input side or after it, leaves `Token In` and
+  the `Amount` line as they read with no permit: a permit of 5,000 DAI to
+  another address and then a V3 exact-in of 600 USDT read `Swap USDT → USDC`
+  with `Amount 600.0000 USDT`, and so do that exact-in and then a permit of
+  5,000 DAI to the router. When a permit's amount stands and the step that sets
+  the input side spends a token other than the permit's, or one the decoder does
+  not know, that step's amount gets lines of its own, unless it states no amount
+  and the user pays it none of its input token. Each take the total does not
+  count gives three lines after the `Amount` line (after `Token In` when there
+  is none): one of a token other than `Token In`; one of `Token In` after an
+  amount that is not a quantity (a V4 open delta, `ALREADY_PAID`, which keep
+  their wording on the `Amount` line, or no stated amount, as of a V4 exact-out
+  step); and one whose amount the decoder does not know. When the step that sets
+  the input side states no amount, the user pays it some of its input token, and
+  there is no `Amount` line, that step gets them too whenever another take's
+  lines give a figure, or a `PERMIT2_TRANSFER_FROM` of its token gives one, on
+  the lines below or, into the router, on its `Paid to` line, so that figure
+  cannot read as all that leaves. When it states no amount and the user pays it
+  none of its input token, as when the router pays it, that step takes none of
+  that token from the user's wallet and never gets them, with a permit or
+  without. They come in step order, the step that sets the input side first when
+  it has them: `Moved from the sender`, its amount, worded as the `Amount` line
+  words one, or `Unknown (could not be decoded)` when the decoder does not know
+  it; `Token moved`, giving the token's address as the `Token In` line does; and
   `Moved to`, which reads `The swap step that spends it`. A token the decoder
   does not know gives the `Moved from the sender` line alone. A step may also
   take from the user's wallet what the decoder did not read: a V4 step whose
@@ -3271,11 +3276,19 @@ Currently supported:
   on every router but `UniversalRouterV1`, and otherwise gives the address. A
   move into the router needs none of them, because its `Paid to` line and
   `Token moved into the router` line already give the amount, the token and
-  where it goes, and so its amount is shown once. These lines change neither the
-  `Paid to` lines nor the minimum's label. A step goes unread when its recipient
-  does not decode as an address, when it is a V3 swap step whose path is shorter
-  than one token address or has bytes after its last hop, or when it is a
-  command the decoder does not read: every command other than `PERMIT2_PERMIT`,
+  where it goes, and so its amount is shown once. Every `PERMIT2_PERMIT` whose
+  amount does not stand as the `Amount` figure, before the step that sets the
+  input side or after it, gives three lines, in step order, after those for each
+  `PERMIT2_TRANSFER_FROM`: `Permit2 allowance`, its amount, for example
+  `5000.0000 DAI`, or `Unlimited` for Permit2's maximum; `Allowance token`,
+  giving the token's address as the `Token In` line does; and
+  `Allowance spender`, the address it lets take the token. Only a permit whose
+  amount stands gives none: the `Amount` line gives its amount, `Token In` its
+  token, and its spender is the router. These lines change neither the `Paid to`
+  lines nor the minimum's label. A step goes unread when its recipient does not
+  decode as an address, when it is a V3 swap step whose path is shorter than one
+  token address or has bytes after its last hop, or when it is a command the
+  decoder does not read: every command other than `PERMIT2_PERMIT`,
   `PERMIT2_TRANSFER_FROM`, `V2_SWAP_EXACT_IN`, `V2_SWAP_EXACT_OUT`,
   `V3_SWAP_EXACT_IN`, `V3_SWAP_EXACT_OUT`, `V4_SWAP`, `SWEEP`, `TRANSFER`,
   `PAY_PORTION`, `PAY_PORTION_FULL_PRECISION`, `ACROSS_V4_DEPOSIT_V3`,