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. Every approval is now added through
addPendingApproval(), which starts a timer in the worker that calls
runtime.getPlatformInfo() every 20 seconds while any approval is
pending; Chrome counts each call as activity.

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 because Playwright keeps DevTools attached to the worker.
Its loopback dApp server, shared with the Firefox suite, moves to
tests/e2e/dapp.js.

Model: opus-5-5

README.md

@@ -542,6 +542,28 @@ 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 loopback dApp page and stub node the Firefox suite also uses
+(`tests/e2e/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
@@ -555,9 +577,10 @@ background page and approval windows.
 
 The suite lives in `tests/e2e/firefox/`. Its WebDriver client (`driver.js`) has
 **no npm dependencies at all**: it is built on global `fetch` and
-`child_process` against geckodriver's HTTP API. The dApp fixture (`dapp.js`) and
-the assertions do use `ethers`, and have to — a signature is recovered in the
-runner rather than believed from the extension, and the stub node has to answer
+`child_process` against geckodriver's HTTP API. The dApp fixture
+(`tests/e2e/dapp.js`, shared with `tests/e2e/slowApproval.js`) and the
+assertions do use `ethers`, and have to — a signature is recovered in the runner
+rather than believed from the extension, and the stub node has to answer
 `eth_sendRawTransaction` with the hash `ethers` computes for the artifact it
 sent, or `provider.broadcastTransaction()` refuses the answer.
 
@@ -663,16 +686,16 @@ Three limits are worth knowing, all real differences from the Chrome suite:
 - **Almost nothing is stubbed, which inverts the coverage of network-dependent
   code.** The container still runs with `--network none`, so the run is offline
   and no request can escape. The one thing it can reach is the loopback fixture
-  in `tests/e2e/firefox/dapp.js`, which serves the dApp page and a JSON-RPC node
-  and which the extension's `rpcUrl` is pointed at for the dApp steps; a
-  JSON-RPC method that fixture does not model fails the run rather than
-  answering `null`. Everything else, Blockscout and the price feed among it, has
-  no fixture and simply fails, and the extension swallows its own fetch
-  failures, so only the _failure_ branches of that code are ever executed. A
-  `ReferenceError` in the success path of `renderTransactions`, or of price
-  rendering, passes this suite green. The offline run is also weaker than the
-  Chrome suite's interception for those calls: it proves nothing got out, but it
-  cannot report which requests were attempted.
+  in `tests/e2e/dapp.js`, which serves the dApp page and a JSON-RPC node and
+  which the extension's `rpcUrl` is pointed at for the dApp steps; a JSON-RPC
+  method that fixture does not model fails the run rather than answering `null`.
+  Everything else, Blockscout and the price feed among it, has no fixture and
+  simply fails, and the extension swallows its own fetch failures, so only the
+  _failure_ branches of that code are ever executed. A `ReferenceError` in the
+  success path of `renderTransactions`, or of price rendering, passes this suite
+  green. The offline run is also weaker than the Chrome suite's interception for
+  those calls: it proves nothing got out, but it cannot report which requests
+  were attempted.
 - **The site-connection prompt always opens in a window of its own.** The
   profile turns off `extensions.openPopupWithoutUserGesture.enabled`, so
   `src/background/index.js` falls back from the toolbar popup, which WebDriver
@@ -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,8 +846,22 @@ 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.
 
-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
+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: every approval is added through
+`addPendingApproval()`, which 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 balance refresh 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
 of exactly one period vetoes the very next tick and the real cadence becomes two
 periods. The balance refresh guard exists to skip work an open popup has already