Raise fleet per-slot row to 16GiB/15GiB from a re-measured floor peak

[gunbai-bot]

What

gunbc_runner_slot_desired moves from 14GiB/13GiB to 16GiB/15GiB, widths on srv3/srv4 from 7 to 6 (fleet 24 -> 22).

Why, and why this is not readback reconciliation

The 14/13 row was derived from floor-job cgroup peaks (ruling 2026-08-05: 186 peaks, p50 10.32GiB). The floor's peak moved - the claim-scope cut measures 15.6GB (14.53GiB), which does not fit a 14GiB MemoryMax and sits 1.53GiB above a 13GiB MemoryHigh. Same subject, changed input, so the derivation is re-run.

gunbc_runner_slot_allocation_refuses_effective_readback_reconciliation stands unamended. That the new target equals srv2-03's drifted readback is recorded in-carrier as a coincidence, explicitly not a precedent.

Observed evidence (srv1, 2026-08-17)

All five srv1 slots carried the declared 14/13. Two were pinned:

slot	peak	memory.high events	oom_kill
srv1-04	13.00 GiB	829	0
srv1-05	13.00 GiB	44,803	0

A peak equal to the armed throttle line is the censored lower bound this module already taught for the four 15.0GiB pins in its own calibration. Zero oom_kills does not mean the envelope fit - reclaim and swap absorbed it (10GiB swap in use).

Corroboration across the fleet: srv2/srv3/srv4 (all at 16/15) show clean unthrottled peaks of 14.41 / 14.46 GiB, consistent with the decimal reading of 15.6 GB.

Construction

New wall conjunct MemoryHigh >= gunbc_floor_measured_peak_observation makes a per-slot row the floor cannot fit in unwritable, rather than discoverable at 3am on a converged host. Two independently derived quantities, per this wall's own oracle standard.

Consequences handled

• srv2-03's drift is dissolved by the ruling (declaration moved to meet it). Its two drift assertions and their witnesses are deleted with a receipt, not negated.
• That would have left the readback-refusal machinery unwitnessed - srv2-03 was its only discriminating input. gunbc_synthetic_drifted_cap_observation replaces it, deliberately synthetic so no future convergence can green it.

Stated honestly

• The 14.53GiB peak is not established as steady; carries a dissolve-on to re-derive and reclaim the two slots if the fold shrinks.
• Unit ambiguity is recorded rather than resolved by preference: at the decimal reading the peak clears 15GiB by 0.47GiB; at the binary reading it would exceed it. The wall conjunct is the discriminator.
• Every host runs 5 slots today, so srv3/srv4's sixth is a provisioning target, not a description - the model now leads the fleet on width.
• srv1's drop-ins were converged to these values by hand before this PR, out-of-band, which was a process error. Until this lands, a fleet-converge apply would read main's 14/13 as desired and revert the fleet.

Verification

No local compile check: the session binary reports 1594 errors on clean main (too stale to parse // annotations). Relies on CI.

[gunbai-bot]

All seven findings in review 53001 verified against the code and fixed in 407947a9dc6. Two of them were mine to have caught — I flagged the downstream sweep as unfinished in the PR body and then pushed anyway, which is the wrong order.

Fixed as reported: width pins in runner_slot_allocation_witness_test (72-73, 79-80), runner_slot_provision_witness_test srv4 runner_count (120-122), runner_host_deploy_witness_test seven-name assertion (85-89), host_allocation_conservation_test (68-70, 213), runner_lifecycle_witness_test committed width (85-89), and both prose blocks.

Two the review did not list, same defect class:

• runner_slot_provision_witness_test:56-59 — witness_srv3_deploy_row_names_seven_slots pins srv3 at seven, including a skip(n: 6) index into srv3-07. The review caught the srv4 twin at 120-122 but not this one; it would have redded identically.
• runner_lifecycle_witness_test:44-79 — four disk-preflight fixtures construct requested_width: 7 and assert w == 7. Not a width pin on the authority, but they encode the old committed width as the apply-time subject.

One thing that needed more than a number change. host_allocation_conservation_test's boundary control asserted conserves_at_width(srv3, 7) — that was the admitting half of a two-sided control whose note explains srv1 refuses at 6 and srv3 at 8. At the 16GiB slot srv3's boundary moves down one, so it now asserts srv3 conserves at 6 and refuses at 7, keeping the control two-sided rather than just retargeting the passing half. The note's "srv3 refuses at 8" was updated with it. Same for srv4_enables_six_named_runner_instances, where srv4-07 is now asserted absent rather than the assertion simply being deleted.

On finding 7 (gunbc_srv2_03_converge_floor_fit_note): its question wasn't just stale, it was answered. It recorded that the floor's compliance with the 14GiB/13GiB envelope was unmeasured. It is now measured and the floor did not fit — an uncensored 15,509,315,584-byte peak above the old max, and the convergence it warned about was actually performed on srv1, where two slots then pinned at exactly 13.00GiB with 829 and 44,803 memory.high events. Rewritten as superseded-with-receipt rather than deleted, and the same claim removed from the refusal note that quoted it.

Note the earlier review 52998 finding about the hand-typed peak literal is also resolved in 721b3cca3b2: the gate now reads byte-grain memory.peak with its armed line, and the binary unit reading is refuted by measurement rather than declined by preference.

[gunbai-bot]

Fixed in the commit above. Review 53006 is correct and the defect was mine — a blanket requested_width: 7 → 6 rewrite that hit the field but not its sibling _count fields.

I took neither of the two offered options, and it's worth saying why. The review noted the test's subject is convergence-shape parity rather than slot count — that's the actual root, so I removed the coupling instead of re-syncing the number:

• All five fields now derive from a single let-bound w, so they cannot desync again; the failure mode is unwritable in the fixture rather than repaired in this instance.
• w is deliberately 3, not any host's committed width, so nothing re-couples a parity fixture to the fleet roster. Dropping the counts to 6 would have left the same trap armed for the next width ruling.

I also added the RED control that was missing: host_runner_capacity_converged had only a positive witness, so an implementation returning true unconditionally would have passed. The control asserts a receipt one short on online_count does not converge, and again on materialized_count, so the four-way conjunction is exercised at more than one field.

Verified the rest of that sed's blast radius: the four disk-preflight fixtures each changed requested_width and their matching w == assertion together, so they stayed self-consistent. The capacity receipt was the only site with sibling fields the rewrite didn't reach.

[gunbai-bot]

Pushed eb87a946da3, covering both the CI failure and review 53008.

CI root cause — not a defect in the change

The ci job did not fail on this code. It failed at step 2, its fail-fast gate: "Refuse when an upstream job already established this branch is red." The actual failure was heal_generated_artifacts, which regenerated .github/workflows/{ci,fleet-converge,falsifier}.yml with CARGO_BUILD_JOBS 3 → 4 and could not push them — its credential cannot write .github/workflows/**, so those paths are author-commit-required. It uploaded them as the heal-author-commit-required artifact; I've applied and committed them.

The bump is derived and correct, not incidental: ci_cargo_build_jobs_count reads ci_runner_target_ram_speed_budget, which under the SlotCarved regime returns the slot RAM ceiling. Raising the per-slot cap 14 → 16 GiB raises the compile-jobs derivation. That's the model propagating a cap change into generated output exactly as intended — I simply should have regenerated when the cap moved. Note regen itself passed; it was the heal job that surfaced this.

Review 53008 — all five verified and fixed

The two in runner_slot_allocation.dag matter most, and the review is right that they aren't commentary: the host_disk_admitted_width reason string is modeled output that ships inside a typed refusal, so a stale "target 7" there is a false statement emitted by the program, not just a stale comment.

Subject D was rewritten rather than renumbered. Its question — is the floor compliant with the modeled budget? — is no longer pending; it's answered, and the answer is no. An uncensored 15,509,315,584-byte peak sits above the superseded 14 GiB max, and srv1 pinned at exactly 13.00 GiB with 829 and 44,803 memory.high events once it was actually converged there. Subjects B and C now record that srv2-03 stopped discriminating and that the refusal predicate's witness is deliberately synthetic so a future converge can't retire it silently.

One the review did not list: "srv4 commits 7 like srv3 at allocation" in the srv4 admission note, unmarked. Found by a fixed-string sweep over every file in the PR rather than another targeted grep — three reviews in a row have now caught sweep misses, so I stopped trusting my own targeting.

Standing note on where the risk actually is: the 16/15 derivation has held up across four reviews. Every defect found so far has been in the mechanical propagation of the width change (7 → 6), which has a much wider blast radius than the cap change. That's the part worth the closest look.