test: drive ConfirmTx in the e2e suite, gate assertion included (closes #238)

ConfirmTx -- the screen that decides what gets signed -- had no automated
coverage of its own behaviour. The arithmetic underneath was well tested; the
wiring was not, so a mutant making the spend gate read the displayed fee
estimate instead of the reserve would have reintroduced the #154 overspend with
the suite still green.

Nine end-to-end tests now drive it for both the native and ERC-20 paths,
covering the pending, funded, over-balance and estimate-failed states, and
asserting that the gate reads the reserve rather than the estimate. Swapping the
two makes the suite fail. The view height is asserted constant across every
state transition rather than merely printed.

Reaching the screen needs a funded balance and a gas estimate, so the route
interception gains fixtures for both. Testing the estimate-failed state means
provoking the console error the code is supposed to emit, which the harness
otherwise fails a run on; an expectation mechanism consumes exactly one matching
record, is scoped to the declaring test, and fails that test if nothing matched,
so it cannot mask an unrelated error.

README.md

@@ -146,6 +146,23 @@ fixtures in `tests/e2e/network.js`, so the run is deterministic and fully
 offline; unrecognised outbound requests are reported as failures rather than
 silently allowed.
 
+It also covers the confirmation screen, for both a native ETH send and an ERC-20
+send: Send disabled while the fee estimate is in flight, enabled once it lands,
+the fee block quoting the expected cost and the reserve separately, the distinct
+message for an estimate that failed, and the view height staying constant across
+every one of those transitions. The load-bearing one is that the spend gate uses
+the **reserve** and not the displayed **estimate** — the two are stubbed far
+apart on purpose, and the funded and refused sends sit on opposite sides of the
+reserve while sitting on the same side of the estimate, so swapping the two in
+`src/popup/views/confirmTx.js` fails the suite instead of passing it. That is
+what [#154](https://git.eeqj.de/sneak/AutistMask/issues/154) was, and it was
+previously correct by reading only.
+
+Any test that drives a failure path on purpose declares the `console.error` it
+is about to provoke, via `errors.expect()`. That is not a mute: the declaration
+consumes exactly one matching record, and a declaration nothing matched fails
+its test just as an undeclared error does.
+
 That reporting has one bound worth knowing. Observation ends when the browser
 context is torn down, and nothing can watch traffic after that, so the run keeps
 collecting for a fixed grace period after the last test returns