test: drive the EIP-1193 dApp approval round trips in the browser (closes #183)

The seam between the content script, the inpage provider, the background worker
and the approval popup had no coverage at all. The unit suite covers each side
in isolation, so a wallet that signed the wrong payload, handed back a signature
from the wrong key, hung on a rejected prompt, or put the user's password back
on the extension messaging boundary would have passed everything.

Ten end-to-end tests now drive it. The route handler serves a local test page on
a reserved-TLD origin; window.ethereum arrives there from the shipped MAIN-world
content script, not from anything the fixture installs, and the page's own
EIP-6963 announcement is required to be that provider by object identity. The
page then speaks eth_requestAccounts, personal_sign, eth_signTypedData_v4 and
eth_sendTransaction through the real prompts, approved and rejected.

The assertions are the point:

  - every signature is recovered in the runner with verifyMessage,
    verifyTypedData and Transaction.from(), and compared against the active
    address read out of extension storage. The background verifies too; nothing
    here leans on its verdict.
  - the transaction is checked against the raw signed bytes captured at
    eth_sendRawTransaction, which the RPC stub now records and answers with the
    transaction's real hash. Signer, recipient, value, call data and chain id
    are all compared there, and the hash the page received is required to be the
    hash of those bytes.
  - a rejected prompt must reach the page as a rejection rather than hang or
    resolve, and must carry EIP-1193 code 4001 across the boundary. The code is
    asserted on the wire because that is where it survives: the inpage provider
    rebuilds the rejection as a bare Error, so the calling page catches a message
    and no code. Reported, not asserted either way.
  - the password must appear in no message the approval window sends to the
    background, observed directly by wrapping chrome.runtime.sendMessage before
    Approve is clicked, with the response message that would carry it required
    to be present so the check cannot pass on an empty record.

Every one of those was run against a deliberately broken variant and seen to
fail: a corrupted recovered signer, a payload carrying the password again, a
provider that resolves instead of rejecting, and approval screens displaying the
wrong message, value and call data.

Two honest limits. The RPC is stubbed throughout, so this does not discharge a
real dApp with real funds against a real network. And the site-connection prompt
goes through chrome.action.openPopup(), whose browser-action popup headless
Chromium will not expose as a page, so that one prompt is driven at the URL the
extension puts on the action instead — same page, same approval id, but a real
toolbar click is not observable from a headless harness. Both are stated in
README.md rather than presented as covered.

Test-only: nothing under src/ changes.

TODO.md

@@ -45,6 +45,17 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: The dApp approval round trips are driven end to end in the
+  browser. A test page served by the harness speaks EIP-1193 to the real inpage
+  provider through the real content script, background worker and approval popup
+  for `eth_requestAccounts`, `personal_sign`, `eth_signTypedData_v4` and
+  `eth_sendTransaction`. Every signature is recovered and compared against the
+  active address, the transaction is checked against the bytes handed to the
+  stubbed RPC, each rejection must reach the page as a rejection, and the
+  password must appear in no message the approval window sends — the assertion
+  that gives [#157](https://git.eeqj.de/sneak/AutistMask/issues/157) a permanent
+  floor. This does not discharge a real dApp with real funds against mainnet
+  ([#183](https://git.eeqj.de/sneak/AutistMask/issues/183)).
 - 2026-08-12: A containerized Firefox end-to-end harness
   (`make test-e2e-firefox`) drives the real popup in a real Firefox with the MV2
   build installed as a temporary add-on. Zero npm dependencies — a WebDriver