docs: state the Storybook browser-pool exception (#2336)

Copilot review round 1: "every project inherits availableParallelism() - 1"
overstated the scope. The five forks-pool projects do; web's storybook
project runs the browser pool, whose default is min(12, availableParallelism()
- 1) — the same 7 on this machine, but a different expression, capped on
larger machines and 1 unless headless — and none of the arms measured it. A
maxWorkers set on that project would still apply (getThreadsCount reads it
first), so it is not exempt from the decision, only unmeasured; both files
now say so.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp
Signed-off-by: cliffhall <cliff@futurescale.com>

AGENTS.md

@@ -457,8 +457,12 @@ free to run a full `local:gate`). Raising a budget nobody chose hides no race.
   project, reading the value Vitest resolved for the test — so a per-test
   option, a `describe` option, a project setting and a `--retry` flag all land
   on the same check.
-- **`maxWorkers` stays unset — on measurement, not by omission (#2336).** Every
+- **`maxWorkers` stays unset — on measurement, not by omission (#2336).** The
-  Vitest project inherits `availableParallelism() - 1`. Capping it to 4 was
+  five forks-pool projects inherit `availableParallelism() - 1`; web's
+  `storybook` project runs the browser pool, whose own default is
+  `min(12, availableParallelism() - 1)` and which was not measured (a cap set
+  there would apply, so it is not exempt — it just needs its own numbers).
+  Capping the forks pool to 4 was
   measured at the leased baseline as +14% wall on the web unit suite and +39%
   on `coverage:web` for zero fewer failures (0 of 18 runs either way), so the
   cap is a permanent solo-run cost. The only thing it moved was one test's 5s

vitest.shared.mts

@@ -81,9 +81,20 @@ export const INTEGRATION_TIMEOUTS = Object.freeze({
 /**
  * `maxWorkers` is deliberately unset, here and in every project (#2336).
  *
- * Each project therefore inherits Vitest's non-watch default,
+ * The five forks-pool projects — web `unit` and `integration`, `cli`, `tui`,
- * `availableParallelism() - 1` — 7 on the eight-logical-core M3 this team
+ * `launcher` — therefore inherit Vitest's non-watch default,
- * works on. Keeping it is a choice, not an omission, and this is the
+ * `availableParallelism() - 1`: 7 on the eight-logical-core M3 this team
+ * works on. Web's `storybook` project is the exception: it runs the browser
+ * pool, whose default is a different expression,
+ * `min(12, availableParallelism() - 1)` — also 7 here, but capped on larger
+ * machines because the main thread chokes past ~12 browser workers
+ * (vitest#7871) — and 1 unless the run is headless with file parallelism. A
+ * `maxWorkers` set on that project *would* apply to it (`getThreadsCount`
+ * reads it before falling back), so it is not exempt from this decision;
+ * but nothing below measured it. The numbers are the forks pool's, and a cap
+ * for Storybook would need its own measurement.
+ *
+ * Keeping the default is a choice, not an omission, and this is the
  * measurement it rests on. On `v2/main` @ `f16a51d4` — after the gate lease
  * (#2339) — with the arms interleaved (default / `--maxWorkers=4` / default),
  * three rounds, one worktree, nothing else of ours running: