* test(e2e): stabilize flaky puppeteer e2e tests
The puppeteer-backed e2e cases intermittently timed out, with every
puppeteer test in a run hanging for the full 30s mocha timeout (e.g. run
26625946119 took 29m as ~50 tests each burned 30s).
Two root causes:
- The tests opted into `headless: 'new'`, which in the bundled Chromium
(pptr 19 / Chromium ~115) is markedly slower and flakier to start in CI
than the legacy `headless: true` mode, for no functional gain here.
- The launch retry only caught thrown errors, not hangs. puppeteer's
default launch/navigation timeouts equal the mocha timeout, so a stuck
launch or navigation killed the test before the retry could help.
Switch to legacy headless, and retry the whole launch -> navigate -> read
cycle with a fresh browser, bounding each step with an explicit timeout so
a hang surfaces as a catchable rejection. Puppeteer test timeout is raised
to fit the retry attempts plus backoff.
* test(e2e): upgrade puppeteer to v25 to fix broken e2e navigation
The puppeteer e2e tests started failing wholesale (all 52 cases timing
out on navigation) after the GitHub-hosted runner image bumped from
ubuntu24/20260518 to ubuntu24/20260525. puppeteer was pinned at 19.11.1,
whose bundled Chromium (~115, mid-2023) launches but can no longer
navigate on the newer OS, while curl through the same proxy still works.
Upgrade puppeteer to v25, which ships a current Chromium built for the
new image. Adjust the two renamed launch options:
- `ignoreHTTPSErrors` -> `acceptInsecureCerts`
- `headless: 'new'` -> `headless: true` (the `'new'` value was removed; the
modern headless mode is now the default `true`).
This also reverts the earlier launch/navigate retry + per-step timeout
experiment: it was based on a wrong root cause (assumed flaky spawns),
didn't help, and tripled the failing run's wall-clock time by retrying a
browser whose navigation could never succeed.
Verified locally with puppeteer 25 that the new launch options launch and
navigate, both directly and through an HTTP proxy.
