fix: WaitTx and TransactionDetail use the network the transaction was sent on (closes #584)

WaitTx asked the active network's node for the receipt, so after a network
switch a transaction sent on the other network was never found and was
reported as timed out. It now asks the node of the network its chain id
names, through reviewedNetworkProvider(), moved from ConfirmTx into the
shared view helpers so both screens use one function. WaitTx and
TransactionDetail build their explorer links for that network too. A stored
wait or transaction whose chain id names no network is refused on restore,
as a stored ConfirmTx transaction already is.

Model: opus-5-5

README.md

@@ -1891,14 +1891,17 @@ view would leave a wallet one click from deletion.
       no recipient." instead
     - Transaction hash: full hash (tap to copy) + etherscan link
     - Count-up timer: "Waiting for confirmation... Ns"
-- **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. A
-  lookup that fails is retried on the next tick rather than counted as a missing
-  receipt, because a failed lookup says nothing about the transaction; but six
-  failures in a row (60 seconds at the poll cadence) end the wait, so an RPC
-  that never answers cannot leave it running indefinitely. Any lookup that
-  answers resets that count.
+- **Behavior**: Polls `getTransactionReceipt` every 10 seconds. The screen
+  describes the transaction on the network it was sent on, whichever network is
+  active: the receipt is asked of that network's RPC endpoint, the one Settings
+  has for it, and the To and hash links open that network's explorer. 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. A lookup that fails is retried on the next tick rather than counted
+  as a missing receipt, because a failed lookup says nothing about the
+  transaction; but six failures in a row (60 seconds at the poll cadence) end
+  the wait, so an RPC that never answers cannot leave it running indefinitely.
+  Any lookup that answers resets that count.
 - **Transitions**:
     - Receipt found → **SuccessTx**
     - A lookup that answers "no receipt" 60 seconds or more after broadcast →
@@ -1963,7 +1966,8 @@ view would leave a wallet one click from deletion.
 #### TransactionDetail (`transaction`)
 
 - **When**: User tapped a transaction row on Home, AddressDetail, or
-  AddressToken.
+  AddressToken. Its etherscan links open the explorer of the network the
+  transaction was sent on, whichever network is active.
 - **Elements** (grouped into logical blocks using light well containers; field
   labels are self-explanatory so groups have no headings):
     - "Transaction" heading, "Back" button