fix: open no approval window for a site-connection prompt already answered (closes #287)

When a site-connection prompt was decided before the toolbar popup raised
for it had loaded, that popup was torn down, chrome.action.openPopup()
rejected, and the background opened its fallback window for the answered
approval and only then removed it. In the Chrome end-to-end suite the next
test could take that window for its own prompt and lose it under its wait.
openApprovalWindow() now returns before creating a window when the approval
is no longer pending.

The blocklist test clicked its self-closing Reject with a plain click; it
now clicks it as the other site Reject does, with the click witnessed.
README.md and the e2e workflow comment no longer name this issue as what
keeps e2e-chrome from being a required check.

Model: opus-5-5

README.md

@@ -619,13 +619,14 @@ 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. The Chrome suite is
-**measurably flaky under load** — two of six runs of unmutated code on a busy
-machine lost the approval popup out from under the dApp signing wait, always in
-the `#183` section, tracked as
-[#287](https://git.eeqj.de/sneak/AutistMask/issues/287). So a red `e2e-chrome`
-has to be read before it is believed, and that flake is the blocker to ever
-making this a required check. Do not answer it with a retry wrapper: a suite
+That is not only a statement about configuration. Reports of the Chrome suite
+**failing under load** are still open, among them
+[#290](https://git.eeqj.de/sneak/AutistMask/issues/290), runs on a busy machine
+failing with `the extension opened no approval window within 30000ms`, and
+[#446](https://git.eeqj.de/sneak/AutistMask/issues/446), the Settings round trip
+closing the popup before its network switch is saved. 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 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