harden: verify all approval fields and make failed signing retryable (closes #174)

approvalVerify now compares every field of the signed artifact against the
approval, not a subset. Transaction types are allowlisted to 0/1/2 and any
field the module does not check is refused outright, so a future transaction
type cannot smuggle consequential fields past verification -- an EIP-7702
type-4 artifact that delegates the signer's own EOA while matching every
displayed field was accepted before this change. The serialized bytes handed
to broadcastTransaction are compared against the parsed artifact, so the
guarantee covers the bytes that actually go to the node.

Signing failures in the popup are retryable again. To make that safe, an
approval is claimed synchronously before the first await and every path that
resolves or removes one goes through a single chokepoint that refuses a claimed
approval. Without it, closing the approval window, switching the active address
or a late reject would report "User rejected the request." to the dApp while
the broadcast completed -- the user then redoes the transfer at a fresh nonce
and it sends twice.

Failure copy distinguishes the stage reached, so a user is never told to start
again from the site when the first attempt may already have reached the network.

TODO.md

@@ -44,6 +44,15 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: Approval verification became an allowlist — transaction type
+  restricted to 0/1/2 so an EIP-7702 delegation can no longer ride along on an
+  approved transfer, every consequential field compared, the artifact
+  re-serialized from the checked fields alone and its exact bytes required to be
+  the canonical encoding of what was broadcast. One approval now yields at most
+  one broadcast, and every path that retires a pending approval — popup close,
+  active-address change, a late reject — goes through a single chokepoint that
+  refuses to settle an attempt already claimed for signing and broadcast
+  ([#174](https://git.eeqj.de/sneak/AutistMask/issues/174)).
 - 2026-08-12: An address can be removed from an HD or xprv wallet behind a
   confirmation screen that states nothing is destroyed, sharing the deletion
   state transitions with wallet deletion so the selection, site permissions and