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, so the position came out where the browser refused
to create the window ("Bounds must be at least 50% within visible screen
space"), and the request failed with -32603 and no window. It now centres on
the last focused browser window.

Under load a test in the Chrome suite raised its prompt while the previous
test's window was still closing, and either hit that refusal or took the
closing window for its own. The runner now closes every approval window
between tests.

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
@@ -1940,7 +1939,8 @@ 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, never on another approval window still open.
 - **Elements**:
     - "Transaction Request" heading
     - Phishing warning banner (shown when the hostname is on the phishing