Fix N-RUNS/START-REP hardcoded constants; N-REPS increase blocked on reservoir cost, not a bug (FABRIC-3.md §XXIII)

Two real bugs found and fixed while attempting to raise N-REPS from
3 (both harmless only by coincidence at N-REPS=3, since 3 happened
to equal the hardcoded/literal values):

- N-RUNS was `27 CONSTANT`, not derived -- now `N-ID N-REPS *
  CONSTANT N-RUNS`.
- START-REP's run_id decode used a literal `3 *` where it meant
  `N-REPS *` (confirmed against EXEC-STD79-DOE, the serialized
  baseline, which correctly uses N-REPS for the same decode).

Re-verified at N-REPS=3 (amd64): byte-identical to the already-
verified baseline -- 193s, 0 faults, 99/99 tokens every identity,
K conserved on all 656 rows.

Raising N-REPS to 6 was then tested and found to cause real, silent
data loss at full 8-identity scale (rajames 0/198, 00 66/198, 01/02
99/198, 03-06 fully complete) -- same failure class as §XXI defect 2,
just past the budget again since doubling N-REPS roughly doubles
total MSG-SEND volume (24->48).

Measured the reservoir's replenishment directly rather than assume
from source: 40 sends drained it from 21735 to 1; 300s of pure idle
time (zero further sends) brought it back to 2049 -- real, but only
~6.8 units/s, meaning a full refill would take on the order of 53
minutes against a campaign's few-hundred-second runtime. Raising
N-REPS further needs a cheaper per-send cost or an explicit top-up,
not reliance on ambient decay.

Reverted N-REPS to 3 (fixes kept, they're correctness fixes
independent of the value) rather than commit a silently-lossy result.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo

FABRIC-3.md

@@ -3039,3 +3039,60 @@ messaging-coordinated, priority-driven turn order, not shuffle-position-driven)
 LaTeX report comparing this against the §XV/§XVIII serialized baseline -- the actual point of
 building the turn-attractor in the first place.
 
+## XXIII. N-REPS increase attempt: two real bugs fixed, the increase itself blocked on the
+reservoir's real replenishment rate (2026-09-12)
+
+**Two genuine bugs found and fixed on the way to raising `N-REPS` from 3, independent of
+whatever value it ends up at.** `N-RUNS` was a hardcoded `27 CONSTANT`, not derived from
+`N-ID * N-REPS` -- harmless only by coincidence while `N-REPS` was 3 (`9*3=27`). `START-REP`
+computed each run's label via `SR-IDX @ 3 * SR-REP @ + REV@` -- that `3` was meant to be
+`N-REPS` (confirmed against the serialized baseline's own `EXEC-STD79-DOE`, which correctly
+uses `N-REPS` for the identical decode), and was also only correct by the same coincidence.
+Both fixed: `N-ID N-REPS * CONSTANT N-RUNS`, and `SR-IDX @ N-REPS * SR-REP @ + REV@`. Re-verified
+at `N-REPS=3` (unchanged from before the fix) on amd64: byte-identical result to the already-
+verified baseline -- 193s, zero faults, 99/99 tokens every identity, K conserved on all 656 rows
+-- confirming the fix is a genuine no-op at the value already in use, not a hidden behavior
+change smuggled in alongside the real target (raising `N-REPS`).
+
+**Raising `N-REPS` to 6 causes real, silent data loss at full scale --confirmed live, not
+theorized.** A small 2-identity smoke test at `N-REPS=6` passed cleanly (198/198 tokens, 67s) --
+only 12 messaged sends, comfortably inside budget. The full 8-identity campaign did not: `rajames`
+came back with 0/198 tokens, `00` with 66/198, `01` and `02` with 99/198, while `03`-`06` were
+all fully complete. This is the same failure class root-caused in §XXI defect 2 (`MSG-SEND`
+silently no-ops on `MSG-ALLOC` failure, and `STEP-TURN`'s `REP-IDX!` bookkeeping still advances
+regardless) -- rep-granularity batching fixed it at `N-REPS=3` (24 messaged sends), but doubling
+`N-REPS` roughly doubles total send volume (to 48), which was apparently enough to exhaust the
+budget again partway through this run.
+
+**The reservoir does genuinely replenish -- confirmed with a direct measurement, not assumed
+from the source alone.** `stadium.c`'s own reap path credits a reaped cell's remaining heat back
+to its owning VM's reservoir (`stadium_quotas[slot].reservoir += header->heat`), which only
+happens once a message's heat decays to exactly zero via repeated `MSG-COOL-ALL` (`Q-DECAY` =
+65208/65536 ≈ 0.995 per tick). Rather than trust that math blind, it was measured directly: 40
+sends drained Hera's own reservoir from 21735 down to 1, then -- with zero further sends --
+300s of pure idle time brought it back up to 2049. Replenishment is real, roughly ~6.8 units/s.
+
+**But that rate is far too slow to matter on a campaign's own timescale.** At ~6.8/s, refilling
+the full ~21734 budget from empty would take on the order of 53 minutes; a full campaign runs in
+a few hundred seconds. Within any realistic campaign window, replenishment recovers a small
+fraction of what active sending depletes -- raising `N-REPS` further within the current design
+needs either a genuinely cheaper per-send cost (`Q.SLOT`, shared project-wide messaging-economy
+constant, not something to change for one campaign's convenience) or an explicit reservoir
+top-up/harvest mechanism, not reliance on ambient decay.
+
+**Reverted `N-REPS` to 3** (the fixed derivation formula/`START-REP` stride kept, since both are
+real correctness fixes independent of the value) pending a real decision on how to fund a higher
+rep count -- not committing a silently-lossy `N-REPS=6`/`9` result, per the same "don't claim a
+number until it's verified end to end" discipline as the rest of this investigation.
+
+**Also, at Captain Bob's request during this same investigation:** `capsules/init-0.4th`
+through `init-9.4th` were renamed to `workload-0.4th`…`workload-9.4th` (they are alternate boot
+personality capsules, not files `doe.4th` dispatches from -- confirmed by reading `doe.4th`
+itself, which generates its own synthetic workload internally, and `mkcapsule.c`, which
+special-cases only the exact filename `init.4th` as the active `MAMA_INIT` capsule). Discovered
+in the process: `experiments/bare_metal/README.md`'s "Adding a Custom Workload Capsule" section
+documented a `WL-HI`/`WL-LO` dispatch table and a `wl_id` CSV column that don't exist anywhere in
+the current `capsules/` tree or `doe.4th`'s own CSV header -- corrected to describe what's
+actually there. Verified: `mkcapsule --lint` clean, all 3 architectures build with zero new
+warnings, amd64 boots with an unchanged dict_hash/capsule_hash from every prior boot this session.
+