A/B Stage C fetch:compute ratio 3:3 against 6:3 once #669 lands

[WilfordGrimley]

Ask

A/B PR #669's Stage C fetch:compute ratio: 3:3 (as shipped) against 6:3.

Rationale

docs/reports/2026-07-20-pipeline-compute-profile.md separates the two dials cleanly:

• fetch is I/O-bound and scales. Per-card mean 743.0ms, 38.7% of total.
• compute is CPU-bound and backfires when over-parallelised. The same report measured
  concurrency=6 on this work as 3.25x slower per card (0.31x speedup) while burning
  27.7x more CPU-seconds, with avg_cores_busy at 7.45/8.

That is independent empirical support for #669's hard cap of 3 compute workers being correct
rather than merely conservative — and it is also the reason raising the fetch count is safe in
a way raising the compute count is not. Memory is not a constraint (peak RSS 232-290 MiB).

If fetch comes off the critical path, the ceiling becomes the compute pool alone.

Gating

Blocked on #669 landing. There is no point measuring a ratio against a baseline that has not
merged.

Acceptance

• both ratios run against the same cohort on the same host
• cards/s and host-load envelope readings captured for each
• if 6:3 wins, _STAGE_C_FETCH_THREADS moves from 3 to 6 at stage_e_dispatch.py:643 in its own
  PR, stating the Stage C / monolith non-overlap explicitly
• if it does not win, the null result is recorded so nobody re-litigates it