mockd: add --tasks N — a plausible large synthetic table for GUI's DoD

GUI's M1 definition of done is "10 000 synthetic rows scroll at 60 fps with
flat memory over 10 minutes (mockd --tasks 10000)". This flag was missing from
the four unhappy-path flags that did land; the brief's own flag list omitted
it, which is corrected here too.

--tasks seeds a plausible population rather than N copies of one row: varied
state, size (log-uniform 50 KB - 20 GB), category, queue position and
description, drawn from the same category.list / queue.list fixtures the rest
of mockd already serves so a synthetic task can never name a category or
queue those methods don't also return. State distribution is roughly
55% complete / 8% failed / 4% cancelled / 6% paused / 2% retry_wait / 25%
queued, using the new TaskErrorCode taxonomy for failures.

"Progress advances across the whole set, not a handful of live rows" ruled
out the obvious cheap answer. A bounded, rotating pool of concurrently-active
downloads (--active-cap, default 24) is fed continuously from each queue's
FIFO — with the rest of that queue's queuePosition renumbered on every
promotion, as a real scheduler would — and a small fraction of active tasks
hit a transient failure and cycle through retry_wait before rejoining, so the
pool keeps rotating through new rows for the whole run instead of draining
once. Verified over a 10000-task, 60-second run: 61.5 MB RSS flat, and the
active pool's membership meaningfully different after 60s.

tick() only ever walks the active pool plus due retry-wait entries, never the
full task list, so its cost stays flat regardless of --tasks. A manual
download.add is still admitted immediately regardless of --active-cap — a
human driving the GUI by hand must never wait behind synthetic load.

Fixed a latent double-push while building this: any task 'connecting' at the
top of a tick was pushed to the progress batch once for the transition and
again at the loop's unconditional final push, inflating event.task.progress
payloads with a duplicate entry for that taskId. It predates this change (the
original tick() had the same shape) but only became visible once several
tasks are legitimately 'connecting' in the same tick, which --active-cap's
continuous promotion now does routinely.

--seed makes a run reproducible, which matters when a GUI bug only shows up
at a particular row.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV

tools/mockd/README.md

@@ -24,6 +24,9 @@ Defaults: `$XDG_RUNTIME_DIR/velox/velox.sock` and `ws://127.0.0.1:52000`.
 | `--ws-port <n>` / `--no-ws` | loopback WebSocket port, or don't listen |
 | `--progress-hz <n>` | progress event rate (default 4, the contract's ceiling) |
 | `--speed <bytes>` | synthetic per-task speed |
+| `--tasks <n>` | seed `n` plausible synthetic tasks instead of the fixture's two — see below |
+| `--active-cap <n>` | ceiling on concurrently-"downloading" synthetic tasks (default 24) |
+| `--seed <n>` | PRNG seed for `--tasks`, so a run is exactly reproducible (default 1337) |
 | `--slow <ms>` | delay every reply. **Past 750 ms `capture.offer` must fail open.** |
 | `--flaky <0..1>` | answer this fraction of calls with `-32603` |
 | `--drop-connection <s>` | terminate every connection every N seconds |
@@ -33,6 +36,37 @@ Defaults: `$XDG_RUNTIME_DIR/velox/velox.sock` and `ws://127.0.0.1:52000`.
 | `--allow-any-origin` | skip the `moz-extension://` Origin check (debugging only) |
 | `--no-validate` | stop validating params (to see what a client actually sends) |
 
+## `--tasks` — load testing the GUI's table
+
+GUI's M1 definition of done is "10 000 synthetic rows scroll at 60 fps with flat memory
+over 10 minutes (`mockd --tasks 10000`)". That takes more than 10 000 identical rows:
+
+```sh
+npm start -- --tasks 10000
+```
+
+Seeds a plausible population — varied `state`, size, category, queue position and
+description, drawn from the same `category.list` / `queue.list` fixtures the rest of
+mockd serves, so nothing here can name a category or queue those methods don't also
+return. Roughly 55% land `complete`, the rest split across `failed`, `cancelled`,
+`paused`, `retry_wait` and `queued`, plus a bounded pool (`--active-cap`, default 24)
+seeded straight into `downloading`.
+
+That pool is **rotating**, not fixed: as an active task finishes, the next one is
+promoted from its queue's FIFO — with the rest of that queue's `queuePosition` renumbered,
+as a real scheduler would — and a small fraction of "finishing" active tasks fail instead
+and cycle through `retry_wait` before rejoining. Over a ten-minute run this means hundreds
+of distinct rows have shown live progress by the time it ends, not the same handful
+forever, while at any instant the active count stays realistic. A manual `download.add`
+is always admitted immediately regardless of `--active-cap` — a human driving the GUI by
+hand is never made to wait behind synthetic load.
+
+`tick()` only ever walks the active pool plus whatever retry-wait entries just came due,
+never the full task list, so the per-tick cost stays flat regardless of `--tasks`.
+
+`--seed` makes a run reproducible: the same seed always produces the same table, which
+matters when a GUI bug only shows up at a particular row.
+
 ## What is real and what is faked
 
 **Real**, because a client's correctness depends on it: