P4: score sealed prediction 1 — sweep to an actual memory/process ceiling

Summary

Sealed prediction 1 ("Replenishment binds on process/memory count before CPU") is currently INCONCLUSIVE — its scorer needs a threshold crossing on memory or process count, and the metal run never produced one: hostCpuFraction stayed ~0.001 flat and Σ PSS never exceeded 0.41 GB, even at 128 resident microVMs (c=64, the top of the tested ladder). What was observed (CPU demonstrably never bound, knee is replenishment-bound) is consistent with the prediction's direction but is explicitly not a scored result per deploy/microvm/predictions.json §7.4's falsification criterion.

Why this matters (and why it's ranked last)

• This is a completeness item, not a throughput/latency blocker: nothing measured so far suggests memory or process count binds before replenishment does, and the stated goal (throughput-optimized sandbox service) doesn't obviously need this scored to make near-term engineering decisions. It matters for long-horizon capacity planning at extreme density, and for closing out the sealed prediction set honestly (2 supported / 0 falsified / 2 inconclusive / 1 not evaluable — this is one of the two inconclusive ones).
• On a 754 GiB, 72-cpu host, reaching an actual memory/process ceiling at the current ~3 MB PSS/VM unit cost would require a very large sweep (extrapolated back-of-envelope: on the order of 10^5 resident VMs by memory alone) — this is a long-running, resource-intensive experiment, which is the other reason it's ranked last.

What's already known / where to look

• deploy/microvm/predictions.json — prediction 1's exact wording and falsification criterion ("falsifiedBy": "CPU saturating at or before the memory gate first refuses"). Do not edit this file — it's SHA-256 pinned and enforced by pnpm -C experiments exec vitest run microvm-predictions; it was sealed before the first rung specifically so predictions can't be adjusted to fit results.
• Scoring logic: analyzeLadder in experiments/src/microvm-density.ts (detectKnee internally) — it scores structurally from a RungSample ladder's own fields (hostCpuFraction, pssBytes, processCount, etc.), so a new sweep just needs to produce records with a real crossing in one of those fields for the existing scorer to pick it up; no scorer changes should be needed.
• Admission control: remote-worker/internal/vmpool/config.go's MaxCommittedBytes/MemoryReserveBytes gate — this is the actual thing that would refuse admission before a real OOM, and it's configured, not derived from the host's physical RAM (flagged elsewhere as a value that can be "configured inert" if sized wrong for the host). Scoring this prediction meaningfully requires either raising this budget toward the host's real ceiling and sweeping until something gives, or deliberately sizing it low enough to force a crossing on purpose (a different, and arguably less interesting, experiment).

Open questions for the spec

1. Is the goal to find where this host would actually run out (raise MaxCommittedBytes toward the host's real ceiling and sweep c/D until something gives), or to test the admission-control gate itself (deliberately undersize the budget and confirm it refuses cleanly rather than free-running into an OOM)? These are different experiments with the same prediction as a side effect.
2. Given the scale involved (potentially tens of thousands of resident VMs to find a real ceiling), is there a cheaper proxy — e.g., artificially inflating VMOverheadBytes or GuestRAMBytes to force a crossing at a much smaller VM count, trading realism for a tractable sweep size?
3. Does pid_max (4194304, per the E10 rung records' limits field) or another kernel limit bind before memory does at any tractable scale, and is that itself worth knowing even if it's not what the prediction asks about?

Suggested scope for a first cut

A design decision before any run: pick the "test the gate" framing (open question 1) as the tractable first cut, since it's a bounded experiment (deliberately undersized budget, confirm clean refusal) rather than an open-ended search for a real-hardware ceiling.

Part of #256 (P4 epic: next experiments after the metal STOP).

Read deploy/microvm/predictions.json §7.4, then inspect analyzeLadder and detectKnee in experiments/src/microvm-density.ts. Review MaxCommittedBytes and MemoryReserveBytes in remote-worker/internal/vmpool/config.go before choosing the gate-test or real-ceiling framing. Done means a documented sweep produces a genuine memory or process crossing that the existing scorer classifies.