docs(coverage): record why two-core Tier A runs stay serial (#1741)

* docs(coverage): record why two-core Tier A runs stay serial

Answers two review notes on the concurrent Tier A runner with measurements
instead of code changes:

- Two cores stay serial. Two in flight would give each project one Jest
  worker, which runs Jest in-band; on a 2-core / 7 GB container ui-playback
  and web ran out of their 2 GiB default heap. With a 4 GiB heap it passed
  about 15% faster on a warm cache for 1.2 GiB more peak memory. CI runs on
  4 cores. A test pins that the defaults never drop to one worker.
- Per-project output buffering is bounded in practice: a big project with
  every test failing printed 1.8 MB while its Jest process peaked at 850 MB.

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

* docs(coverage): say two-core runs keep two workers per project

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

---------

Co-authored-by: 4gray <fourgray@proton.me>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/validation-map.md

@@ -98,7 +98,10 @@ report, or a runtime-owning production TypeScript file absent from that report.
 It runs projects a few at a time, largest first, with a bounded Jest worker
 count per project (defaults: `min(3, cores - 1)` in flight and
 `ceil(cores / concurrency)` workers each; override with `--concurrency=N`,
-`--max-workers=N` or `TIER_A_CONCURRENCY` / `TIER_A_MAX_WORKERS`). Each
+`--max-workers=N` or `TIER_A_CONCURRENCY` / `TIER_A_MAX_WORKERS`). Two cores
+run one project at a time with two workers. Two in flight would leave each
+project one worker, which runs Jest in-band, and a big project's single heap
+can run out on a small machine; for the same reason avoid `--max-workers=1`. Each
 project's output is printed as one block when it finishes, and the run ends
 with the wall-clock total and the longest projects. Spec `tsconfig`s set
 `isolatedModules: true`, so ts-jest transpiles files one at a time instead of