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

The screen that decides what gets signed had no automated coverage of its
own behaviour: no unit tests, and the e2e suite never reached it. The
arithmetic underneath is well covered in src/shared/txValidation.js; the
gap was the wiring — which number reaches the gate, when the gate re-runs,
what the fee block renders, and whether Send is enabled.

The confirmation screen quotes the fee ESTIMATE (gasLimit * gasPrice) and
gates on the fee RESERVE (gasLimit * maxFeePerGas). Reading the quoted
number instead was issue #154, and until now that was correct by reading
only — a mutant swapping the two passed the whole suite. It no longer
does: two of the new tests fail on it, one per transaction type.

The harness gains a funded-balance fixture to make any of this reachable.
tests/e2e/network.js now serves a configurable ETH balance, an ERC-20
holding, a latest block with a baseFeePerGas (without which ethers has no
maxFeePerGas and the reserve and the estimate collapse into one number),
and decimals() for the stub token. It can also refuse a gas estimate, and
hold one open so the pending state can be observed rather than raced.

Nine tests, over both the native ETH and the ERC-20 path: Send disabled
while the estimate is pending, enabled once it lands, the fee block
quoting both numbers, the distinct message for an estimate that failed,
refusal for a send past the balance, refusal for a send the reserve does
not cover, and the view height constant across every one of those
transitions.

Driving a failure path means provoking the console.error the code is
supposed to emit, which the harness fails a run on. ErrorCollector gains
expect(): it consumes exactly one matching record, and a declaration
nothing matched fails its test just as an undeclared error does, so it
cannot be used to silence anything. Both halves of that were verified by
running the suite against a deliberately wrong pattern.

README.md

@@ -135,6 +135,23 @@ from 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