Load tests with k6, for what many people at once do to the server (#133)

The browser tests drive one person against a handful of feeds, one request at a time, and cannot
show what production's load does. node tests/load/run.js builds a release binary, serves 1,500
generated feeds from itself, starts a daemon of its own under /tmp/ipx-load, seeds a hundred
listeners with thirty feeds each and four downloaded files, and runs four k6 scripts, with
`ipx status` -- the healthcheck -- run every second and failing the run at its 5s timeout:

  browse     25 people at once: feed list, All Subscriptions, a feed, a search, the Directory,
             a feed's page in it
  listening  100 players saving positions every second and marking items read while scans write;
             each reads its own state back, which must be as it left it
  media      50 listeners seeking: every range checked byte for byte against the served file
  signin     a flood of wrong passwords while others browse, and the gap between refusing a
             known name and an unknown one

Each budget is about twice what it measures now. Getting here found #135 (SQLite waiting for the
disk after every write, a first scan of 1,500 feeds estimated at 50 minutes, now 27s), #136
(SQLite's single connection, left open), #137 and #138 (fixed in the commit before this). k6 is
installed from its own signed apt repository by /src/install.sh, outside this repository.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -124,7 +124,8 @@ npx tsc -p .              # type-checks web/src
 node tests/page-smoke.js
 node tests/native-bridge.js  # the page hands playback to a native shell
 node tests/contrast.js    # every theme's palette against WCAG AA
-npx playwright test       # 40 browser tests against a real daemon on fixture feeds
+npx playwright test       # 66 browser tests against a real daemon on fixture feeds
+node tests/load/run.js    # k6: many people at once against a scratch daemon with 1,500 feeds
 ```
 
 Things about the browser suite that have cost time:
@@ -141,6 +142,25 @@ Things about the browser suite that have cost time:
 * `webServer` starts **before** `globalSetup`, which is why the fixture config is written at
   config-load time instead.
 
+The load tests (`tests/load`, issue #133) are for what one browser cannot show: twenty-five people
+browsing at once, a hundred players saving positions while a scan writes, fifty listeners
+seeking through files, a flood of wrong passwords. Things about them:
+
+* They need **k6**, which `/src/install.sh` installs from k6's own signed apt repository, and they
+  build and run a **release** binary: Argon2 in a debug build takes about a second a sign-in,
+  which would measure the build.
+* `run.js` serves the feeds itself, generated, and starts **its own daemon** under
+  `/tmp/ipx-load`, wiped each run, on ports 8793 and 8794, so it can run beside the browser suite.
+  It stops that daemon by its PID. People sign in by the `X-Load-User` header, trusted from
+  127.0.0.1, as production trusts Cloudflare Access's; only the sign-in test uses a password.
+* Each threshold is a budget well above what the request takes now: it is there to catch a query
+  that has started asking once per feed, or writers queueing on a lock, not a slow minute.
+* `ipx status`, the Docker healthcheck, runs every second throughout, and a run fails if one takes
+  the healthcheck's 5s.
+* One at a time: `node tests/load/run.js signin`. All four take about six minutes.
+* The daemon is on **SQLite**, so its numbers carry SQLite's single connection (#136); production
+  is on Postgres, which the harness cannot run on yet (#139).
+
 Non-trivial logic leaves one runnable check behind. Pure functions (`merge_policy`, `pick`,
 `matches_keywords`, `parse_interval`) are the easiest place to put it.