E8: run VM density + saturation (both arms) and record the result #11

Summary

Run E8 — VM density and saturation (P6 §5.2) — and record the result. The spec amendment and driver
work are #10; this issue is the run itself, which #10 explicitly does not cover.

Splitting them is deliberate. #10 lands a two-arm methodology (capacity + realism) and the driver
changes that make a knee reachable; it can be reviewed and merged without any hardware booked. The run
consumes that methodology, produces the number, and is where a bound=not-observed outcome has to be
adjudicated rather than merged. Keeping them in one issue is what let the previous calibrated run be
recorded as a density figure when it was stub-sleep-bound.

Preconditions — all of them, checked before booking anything

Gate 3 is a scoping decision, not a dependency to wait on. Per P6 §3.6, P5 slipping delays a claim,
not the work — so a single-subject E8 is runnable the moment gates 1, 2, 4, 5 hold, and should not be
held behind rossoctl/moca#239.

What to run

Both arms from #10's amended §5.2, each recorded separately and never merged into one figure:

• capacity arm — trivial exec, fast stub profile, sandbox tier non-binding and non-competing.
  Sweep offered concurrency upward with SH_WORKERS × SH_TURNS_PER_WORKER and
  KAGENTI_SANDBOX_CAP set well past the expected knee. Reports an upper bound on the harness
  tier — explicitly not a deployable density.
• realism arm — calibrated duty (e6-ocp basis), stub profile 300/12/64. This is the deployable
  number, sandbox-shaped by construction.

W=1 is a rung, not an aside: it makes "one process would be simpler" a data point (§5.2).

Knee detection reuses E6's sustained-decline detectKnee with degradeX=2 against a warm C=1
baseline, and the knee is reported as a floor, not a ceiling (EXPERIMENTS.md:120).

Acceptance

• Both arms run; each arm's stub profile recorded and pinned via assert_stub_pinned, and the
  arm label verified against what /profile returns
• Per rung: throughput, p50/p95, event-loop lag p99, RSS, per-turn worker CPU, sandbox-container
  CPU, lease saturation, over-admission events, spurious 429s
• Duty basis row and connections per session recorded on every rung, not only sticky ones
• The knee is attributed — worker CPU vs RSS vs replenishment vs admission cap — not just located
• If the capacity arm still returns bound=not-observed, say so and name what bound first; do not
  report a floor as a ceiling
• % of ideal throughput is not reported as a capacity figure when the ideal is stub-sleep-bound
• Single-subject vs mixed-subject scope stated in the record, with the isolation claim made only
  if P5: session identity isolation — per-request subject, no ambient credential moca#239 landed
• Results in deploy/vm/EXPERIMENTS.md, pointer added from docs/experiment-results.md (§5.6)

Open question to settle during the run

Is event-loop lag trustworthy as the capacity arm's headline diagnostic? It read ~11 ms flat at
every rung including c=1, where the tier is nearly idle — which looks like a sampling or timer
artefact. §5.2 makes it the metric that attributes a knee to worker CPU, so verify it against a
deliberately CPU-starved worker before relying on it. If it cannot be trusted, per-turn worker CPU
(#254 §2e) carries the attribution alone and the record should say so.

Related: #10 (spec + driver), PR rossoctl/moca#253 (routing prerequisite), rossoctl/moca#239 (mixed-subject scope), E9 run.