fix: settle a site approval on the port that carries its teardown (closes #275)

Approve and window.close() left the popup on the next line, and the decision
and the disconnect the close caused travelled independent channels with nothing
ordering them. The disconnect handler settled a pending site approval as a
rejection, so whichever landed first decided the outcome. Driven in a tab the
teardown won every time: the user allowed the connection and the dApp was told
they had refused.

The decision now goes out on the approval port the popup already opens, which
is the same port the close disconnects. One channel is ordered -- a message
posted on a port is delivered before that port's own disconnect -- so the
approval is settled before the teardown is even seen, and the disconnect then
finds nothing pending to reject. Nothing waits, nothing is timed, and the popup
closes exactly as immediately as before.

windows.onRemoved no longer decides a site approval whose port is connected
either. In the fallback-window shape that event races the decision on a channel
of its own, which is the same defect one level over; the port disconnect says
the same thing in a defined order, so it is left to say it. A window that
closes before its popup ever connected has nothing else to speak for it and is
still rejected there, so no dApp is left waiting on a window that is gone.

Rejecting reports a rejection, and so does closing without deciding, in both
shapes. AUTISTMASK_APPROVAL_RESPONSE is gone; the port name carries the
approval id, so the popup no longer names one, and the sender check the message
carried moved to the port.

tests/backgroundApproval.test.js drives decide-then-disconnect with nothing
awaited in between, in the toolbar-popup shape that production uses and in the
fallback-window shape, and asserts every close-without-deciding path still
rejects. tests/e2e/run.js drops the deferred-window.close() accommodation it
carried for this bug, so the two site-prompt tests now drive the shipped
decide-then-close in a real Chromium.

TODO.md

@@ -45,6 +45,18 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-14: Approving a site connection is no longer a race against the popup
+  closing. The decision now rides the approval port the popup already holds,
+  which is the same channel the close disconnects, so it is delivered ahead of
+  that disconnect however fast the teardown is; `windows.onRemoved` no longer
+  decides a site approval whose port is connected, since that event is ordered
+  against nothing either. Rejecting and closing without deciding both still
+  report a rejection, and the popup delays its own close by nothing. The e2e
+  harness's deferred-`window.close()` accommodation is gone with it, so the two
+  site-prompt tests now drive the shipped decide-then-close in a real Chromium;
+  against the unfixed code the approval came back to the page as
+  `{"settled":"rejected","code":4001}`
+  ([#275](https://git.eeqj.de/sneak/AutistMask/issues/275)).
 - 2026-08-12: EIP-1193 error codes now reach the page. `src/content/inpage.js`
   rebuilt every failure as `new Error(error.message)`, so the code the
   background produced and the content script relayed intact was dropped in the