harden: verify the signed transaction against what the popup displayed (closes #216)

Verification compared the signed artifact against the dApp's request object.
For every field the dApp omitted -- normally nonce, gas limit and all the fee
fields, since the popup filled them in -- the number the user actually read on
screen was verified by nothing, and only absolute ceilings stood behind it.

The transaction is now populated in the background before the approval window
opens, and that populated object is both what the popup displays and what the
signed artifact is verified against. Every consequential field becomes an
equality comparison; the ceilings remain as a backstop. Population failing
means no approval and no window, and the error goes to the requesting page --
earlier than before, where the same estimate failed after the password had been
typed.

The account is pinned too: `from` is compared against the address named at
approval time rather than whichever address is active at signing, so switching
accounts mid-flow refuses instead of signing from an account the approval did
not name. The message-signing path had the same defect and gets the same fix.

Nonce selection moves earlier as a consequence; the concurrent-approval case
that follows from it is tracked at #271.

docs/README.md

@@ -311,10 +311,15 @@ pages. When a site requests access to your wallet:
    time.
 
 When a connected site requests a transaction, a separate approval popup appears
-showing the transaction details (from, to, value, data). You must enter your
-password and click "Confirm" to authorize it. Message and typed-data signature
-requests work the same way, with a "Sign" button, and also require your
-password.
+showing the transaction details (from, to, value, data, network fee, network and
+nonce). Every one of those values is checked against the transaction that is
+actually signed before anything is broadcast, so what you read on that screen is
+what goes out or nothing does. The popup appears once the wallet has worked out
+the fee and gas from the network, which takes a moment; if that fails, no popup
+appears and the site is told the transaction could not be prepared. You must
+enter your password and click "Confirm" to authorize it. Message and typed-data
+signature requests work the same way, with a "Sign" button, and also require
+your password.
 
 If the requesting site's domain is on the phishing blocklist, all three approval
 screens show a red phishing warning before you decide.