fix: a slow answer to an approval still reaches the site (closes #540)

Chrome stopped the background worker about six minutes after a site's
request even with the approval window open, and the approval and the
site's waiting request went with it. The approval window now posts an
empty message on its approval port every 20 seconds while it is open;
each one is an event, which keeps the worker running.

tests/e2e/slowApproval.js, run by make test-e2e, leaves a transaction
and a signature approval open for seven minutes and requires the site
to receive both results. It drives Chromium over the DevTools pipe
without Playwright, because Playwright keeps DevTools attached to the
worker and Chrome then never stops it.

Model: opus-5-5

README.md

@@ -527,6 +527,24 @@ one profile yields a single extension id, not two: Chrome does not load a second
 copy of an id it already has. The assertions are annotated as observations, so a
 Chrome that ever changes this fails the run instead of passing it.
 
+Last, `make test-e2e` runs `tests/e2e/slowApproval.js`, which leaves a
+transaction approval and a signature approval open for seven minutes, then
+approves both and requires the site to receive the hash of the transaction the
+stub node received and a signature that recovers to the address. Before the
+approval window kept the background worker running, Chrome stopped it about six
+minutes in and neither request was ever answered
+([#540](https://git.eeqj.de/sneak/AutistMask/issues/540)). It is its own program
+and does not use Playwright: Playwright keeps DevTools attached to the
+background worker, and Chrome never stops a worker DevTools is attached to, so
+no wait in the suite above can show the worker stopping. It starts Chromium
+itself, speaks the DevTools protocol over `--remote-debugging-pipe`, and
+attaches to pages only. Before raising the approvals it requires the worker to
+stop on its own with nothing pending, so a run in which something else keeps the
+worker running fails. The site is connected and the RPC endpoint set through the
+extension's own screens, against the Firefox suite's loopback dApp page and stub
+node (`tests/e2e/firefox/dapp.js`). Unlike the suite above, it does not fail on
+page errors.
+
 ### Firefox (`make test-e2e-firefox`)
 
 `make test-e2e-firefox` builds `dist/firefox/` and drives the **real popup in a
@@ -707,11 +725,13 @@ installing Firefox, geckodriver and their system libraries. Both scripts now
 build their image with `--no-cache`, so every run pays the cold figure. Those
 `e2e-chrome` runs predate the cases that wait in real time for a receipt to end
 in error. `make test-e2e` took 3m51s locally with its image cached, so with the
-image rebuilt every run, an `e2e-chrome` run comes to about seven minutes.
+image rebuilt every run, an `e2e-chrome` run comes to about seven minutes. The
+approvals left open for seven minutes (`tests/e2e/slowApproval.js`) add about
+eight more, so about fifteen.
 
 Each e2e job has a `timeout-minutes` cap, so a hung build or browser ends the
 job instead of holding the shared runner: `e2e-firefox` 15 minutes and
-`e2e-chrome` 20, each over two and a half times the job's slowest cold run. A
+`e2e-chrome` 40, each over two and a half times the job's slowest cold run. A
 job that reaches its cap has hung; read it as a hang, not as a slow run to
 retry. The `check` job has no cap: `.gitea/workflows/check.yml` is the canonical
 copy from `sneak/prompts`, kept byte-identical.
@@ -806,6 +826,16 @@ on the next event. Two consequences shape every recurring job in the background:
   service worker at all — the one remaining user of it, `src/shared/ens.js`,
   runs only in the popup and is marked as such.
 
+Pending approvals are the exception: an approval waiting for the user, and the
+site's request waiting on it, live only in the worker's memory, and only the
+worker that received the request can answer it. Chrome stopped the worker about
+six minutes after a site's request even with the approval window still open, and
+the user's answer then reached nobody. So while an approval window is open it
+posts an empty message on its approval port every 20 seconds, and each message
+is an event that keeps the worker running: an approval stays answerable however
+long the user takes. A worker that stops for another reason, a crash say, still
+loses the approvals open in it.
+
 The job also carries a freshness guard, and a guard must never be timed to the
 alarm period it gates. The guard is measured from the moment the last run
 finished, which is one run-duration after the alarm that started it, so a guard