fix: WaitTx timeout no longer overwrites a rendered success screen (closes #155)

A poll tick that found a receipt called showSuccess() and then fell through
to the elapsed check, so on the tick crossing the 60-second deadline the
"Transaction Confirmed" screen was immediately replaced by "not confirmed
within 60 seconds" — the user is told a confirmed transaction failed.

The wait now has an explicit lifecycle. A wait id is bumped by endWait(),
which is called on receipt, on timeout, when a new wait starts and when the
user navigates away; every timer callback and every post-await continuation
checks it, so exactly one outcome can be rendered per wait and no stale
timer or in-flight receipt lookup can touch a view it no longer owns.

The wait is also persisted (state.viewData.pendingWait) and "wait-tx" is now
restorable: reopening the popup resumes the poll with the elapsed counter
and the deadline still measured from the original broadcast, instead of
silently abandoning the wait. Polling stays in the popup rather than moving
to the background, which would depend on setInterval surviving in an MV3
service worker.

The 60-second threshold and the timeout copy are unchanged.

README.md

@@ -504,10 +504,14 @@ transitions.
     - To: color dot + full address + etherscan link
     - Transaction hash: full hash (tap to copy) + etherscan link
     - Count-up timer: "Waiting for confirmation... Ns"
-- **Behavior**: Polls `getTransactionReceipt` every 10 seconds.
+- **Behavior**: Polls `getTransactionReceipt` every 10 seconds. The wait is
+  persisted: closing and reopening the popup resumes the poll, with the elapsed
+  counter and the timeout deadline still measured from the original broadcast.
 - **Transitions**:
     - Receipt found → **SuccessTx**
     - 60 seconds without confirmation → **ErrorTx** (timeout message)
+    - Exactly one of the two: a receipt found on the tick that crosses the
+      deadline wins, and neither outcome can be rendered over the other
 
 #### SuccessTx