fix: closing a transaction or signature approval window leaves the request pending (closes #673)

The browser can close the approval window when the user clicks away from it,
for example to copy the password from a password manager. Closing it used to
reject the request with 4001. Now the request stays pending and the site gets
no answer. Until it is answered, the toolbar popup opens the oldest such
approval. The toolbar popup skips an approval while its transaction is being
sent or its signature checked. A worker that starts holds no approvals, so it
points the toolbar popup back at the wallet.

Reject now closes its window only after the background has the rejection. A
rejection the background refuses leaves the window open with the background's
message.

Site-connection and network-switch windows still reject the request when
closed.

Model: opus-5-5

README.md

@@ -512,10 +512,9 @@ window of its own, and the password is required to be absent from every message
 the approval window sends to the background — with the message that would carry
 it required to be present, so that check cannot pass by observing nothing. That
 last one is the standing floor under
-[#157](https://git.eeqj.de/sneak/AutistMask/issues/157). Closing a transaction
+[#157](https://git.eeqj.de/sneak/AutistMask/issues/157). A transaction or
-or signature approval window is required to leave the dApp's request unanswered.
+signature approval whose window is closed is required to leave the page without
-The suite then opens that approval at the URL the toolbar button holds, and
+an answer. The suite then answers it from the page the toolbar button opens.
-answers it there.
 
 The limits of that coverage and of the rest of the Chrome suite, none of them
 papered over:

src/background/index.js

@@ -161,9 +161,9 @@ let txApprovalSlot = null;
 const APPROVAL_PENDING_CODE = -32002;
 
 // True at every moment this can be sent: the slot is taken immediately before
-// the transaction is populated, so the other request is being prepared, is on
+// the transaction is populated, so the other request is either being prepared
-// screen, or waits with its window closed. It does not claim the other one is
+// or on screen. It does not claim the other one is displayed yet, because for
-// displayed yet, because for the length of one network round trip it is not.
+// the length of one network round trip it is not.
 const TX_APPROVAL_PENDING_MESSAGE =
     "AutistMask handles one transaction at a time, and another one is" +
     " already in progress, so this one was not sent. Please finish that" +