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.

TODO.md

@@ -44,6 +44,14 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: The transaction confirmation screen has browser coverage. The
+  end-to-end suite reaches ConfirmTx for both the native ETH and the ERC-20 path
+  off a funded-balance fixture, and asserts the pending, funded, over-balance
+  and estimate-failed states, the fee block quoting the estimate and the reserve
+  separately, and a constant view height across every one of those transitions.
+  The load-bearing assertion is that the spend gate reads the reserve and not
+  the displayed estimate: swapping the two fails the suite
+  ([#238](https://git.eeqj.de/sneak/AutistMask/issues/238)).
 - 2026-08-12: An xprv wallet already in storage that was imported from a
   non-master key is detected from the depth of its stored `xpub`, explained in
   the wallet list, and blocked from signing, sending and private-key export