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. While any approval is pending, the
worker now calls runtime.getPlatformInfo() every 20 seconds; Chrome
counts each extension call as activity. The timer is the worker's own,
so a minimized window does not slow it, and it stops itself once nothing
is pending.

tests/e2e/slowApproval.js, run by make test-e2e, leaves a transaction
and a signature approval open for seven minutes in minimized windows 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

@@ -542,6 +542,29 @@ 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 with both
+windows minimized, then restores and 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 background worker kept itself running while
+an approval is pending, Chrome stopped it about six minutes in and neither
+request was ever answered
+([#540](https://git.eeqj.de/sneak/AutistMask/issues/540)). The windows are
+minimized through the DevTools protocol (`Browser.setWindowBounds`), and the run
+fails unless both pages then report themselves hidden: Chrome slows a hidden
+page's timers to once a minute, so anything the window did to keep the worker
+running would fail here. 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
@@ -722,11 +745,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.
@@ -821,6 +846,20 @@ 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. Left alone, 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 the worker keeps
+itself running while any approval is pending: raising an approval starts a
+`setInterval` that calls `runtime.getPlatformInfo()` every 20 seconds, and
+Chrome counts each extension call as activity. The timer stops itself once
+nothing is pending, and the worker then stops as it otherwise would. The timer
+is the worker's own, so it does not depend on the approval window being visible;
+a timer in the window would, because Chrome slows a hidden page's timers to once
+a minute. 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