docs(ci): scope the RSS rule to the in-flight term

The `--jobs` sizing guidance read as a process-wide bound, and it is
one only where the destination does not retain finished results.
`metrics --output <FILE>` sends every space over an unbounded channel
and collects it after the walk, and structured stdout holds completed
documents while an earlier file is still being analyzed — worst
exactly when one large file sorts early, which is the shape this
change was measured on. `--output-dir` writes per document and
`bca check` reduces each file to its violations, so those two stay at
the in-flight bound.

State the formula as the in-flight term, name the destinations that
add a result-set term, and point a memory-limited runner at
`--output-dir`.

Author: dekobon

CHANGELOG.md

@@ -40,7 +40,9 @@ for historical reference.
   `-j 16`: 488 MB → 439 MB. No metric value moves. What remains is
   dominated by the parse rather than by the walk: a parse-only
   `bca dump` over the same files peaks at 25–70× the source size, which
-  the CI recipe now states as the `--jobs` memory sizing rule.
+  the CI recipe now records as the in-flight term in its `--jobs` sizing
+  guidance — alongside the destinations that add a result-set term on
+  top of it (`metrics --output <FILE>`, structured stdout).
 
 ### Changed
 

big-code-analysis-book/src/recipes/ci.md

@@ -869,11 +869,20 @@ Applies regardless of provider:
   macOS/Windows — so CI runners no longer need to thread
   `--jobs "$(nproc)"` through every recipe. `--jobs 1`
   remains a debugging knob, not a default. It is *not*
-  memory-aware: each worker holds one whole file in memory at a
-  time, and a parse-only run measures 25–70× the source size, so
-  peak RSS is roughly `jobs × 70 × the largest source file` in
-  the tree. A memory-limited container with many vCPUs should
-  pass an explicit `--jobs`.
+  memory-aware. Each worker holds one whole file at a time and a
+  parse-only run measures 25–70× the source size, so the
+  *in-flight* term is roughly `jobs × 70 × the largest source
+  file` in the tree — and `--jobs` bounds that term only.
+  Whether it is the whole story depends on the destination:
+  `--output-dir` writes each document as it is produced and
+  `bca check` reduces each file to its violations, so both stay
+  at the in-flight bound, while `metrics --output <FILE>`
+  collects every file's result and serializes it after the walk,
+  and structured stdout holds finished documents while an
+  earlier file is still being analyzed — which is worst when one
+  large file sorts early. A memory-limited container with many
+  vCPUs should pass an explicit `--jobs`, and prefer
+  `--output-dir` to `--output <FILE>` on a large tree.
 - **Always pass `--strip-prefix "$PWD/"` to `bca report markdown`**
   so the path column is identical across runners with different
   workspace paths. Without it the diff between two reports is