fix: open an approval window while another one has focus (closes #290)

The background centred each approval window on the last focused window,
which could be an earlier approval window still open; headless Chrome
reports one as 1280x720, the browser refused the resulting position, and
the request failed with no window. It now centres only on a browser
window, and when the browser refuses a position it asks again without one.

In the Chrome suite a test could raise its prompt while the previous
test's window was still closing. After a passed test the runner now gives
approval windows five seconds to close and fails the test if one is still
open; after a failed test it closes them.

Model: opus-5-5

README.md

@@ -381,11 +381,13 @@ handler on a reserved-TLD origin, gets `window.ethereum` from the shipped
 the runner and compared against the active address, the transaction assertions
 run against the raw signed transaction captured at `eth_sendRawTransaction`
 rather than against anything the extension reported, rejecting each prompt is
-required to return a rejection to the page rather than hang or resolve, 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).
+required to return a rejection to the page rather than hang or resolve, a prompt
+raised while another approval window has focus is required to open a 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).
 
 Two limits of that coverage, neither of them papered over. The RPC is stubbed
 throughout, so this is **not** a real dApp against a real network with real
@@ -619,12 +621,9 @@ The jobs **report, they do not gate.** A failure is a red mark against the
 commit that a reviewer has to account for, not a hard block: whether a check
 blocks a merge is Gitea branch protection, which this repo does not configure.
 
-That is not only a statement about configuration. A report of the Chrome suite
-**failing under load** is still open:
-[#290](https://git.eeqj.de/sneak/AutistMask/issues/290), runs on a busy machine
-failing with `the extension opened no approval window within 30000ms`. So a red
-`e2e-chrome` has to be read before it is believed, and those failures are the
-blocker to ever making this a required check. Do not answer them with a retry
+That is not only a statement about configuration. No report of the Chrome suite
+**failing under load** is open now, but it has failed that way before, so a red
+`e2e-chrome` is read before it is believed. Do not answer one with a retry
 wrapper: a suite that reruns until it is green stops being evidence.
 
 Nothing in either job can pass vacuously. There is no `continue-on-error` and no
@@ -1958,7 +1957,9 @@ view would leave a wallet one click from deletion.
   `eth_sendTransaction` arriving while one is unanswered is refused with
   EIP-1193 code `-32002` rather than being populated at the same nonce. It opens
   no window and takes no nonce, and the site can send it again once the pending
-  one is answered.
+  one is answered. The window is centred on the browser window the user was last
+  in; if that was another approval window, or the browser refuses the centred
+  position, the browser picks the position.
 - **Elements**:
     - "Transaction Request" heading
     - Phishing warning banner (shown when the hostname is on the phishing