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.

README.md

@@ -1041,7 +1041,12 @@ on ConfirmTx, DeleteWallet, ApproveTx and ApproveSign.
 - **When**: A connected website requests a transaction via
   `eth_sendTransaction`. Always opened in a separate popup window by the
   background script (`windows.create()`), because the request is triggered
-  programmatically rather than by a user gesture.
+  programmatically rather than by a user gesture. The background populates the
+  transaction (nonce, gas limit, fees, chain id) against the RPC node _before_
+  opening the window, so the screen shows a complete transaction and the signed
+  artifact can be compared with it field for field. A request that cannot be
+  populated — unreachable node, reverting gas estimate — opens no window and is
+  failed back to the site.
 - **Elements**:
     - "Transaction Request" heading
     - Phishing warning banner (shown when the hostname is on the phishing
@@ -1053,13 +1058,16 @@ on ConfirmTx, DeleteWallet, ApproveTx and ApproveSign.
     - Contract: color dot + full address + etherscan link (or "contract
       creation"), token symbol label if known
     - Value: amount in ETH (4 decimal places, USD in parentheses)
+    - Network fee (max): gas limit × fee per gas in ETH (4 decimal places, USD
+      in parentheses), with the gas limit and the fee per gas in gwei below it
+    - Network and nonce
     - Raw data: full calldata displayed inline (shown if present)
     - Password input and an error line
     - "Confirm" / "Reject" buttons
 - **Transitions**:
-    - "Confirm" (correct password) → decrypts and signs in the popup, hands the
-      signed transaction to the background to broadcast, then → **WaitTx** in
-      the same popup window
+    - "Confirm" (correct password) → decrypts and signs the transaction it was
+      shown, exactly as shown, hands the signed transaction to the background to
+      broadcast, then → **WaitTx** in the same popup window
     - "Confirm" (wrong password) → error line, no screen change
     - "Reject" → closes popup (returns rejection to background)
     - Popup window closed without answering → the request is rejected with