Source cores_per_slot from a workload reserve, not a VM price list

[gunbai-bot]

cores_per_slot read gunbc_runner_memory_per_core_reading(), the Ubicloud
aarch64 survey, uniform at 3.0 GB/vCPU decimal. That is Ubicloud's commercial
proportioning of an Ampere Altra Q80-30 (80 cores); our hosts are Altra Max
M128-30 (128 cores), and the figure was answering a different question: how
much CPU one CI slot NEEDS, which is a fact about the workload.

The workload is the required floor and it is SINGLE-THREADED (operator,
2026-09-19). At the 26 GiB slot the surveyed ratio answered 10 cores, so the
CPU axis admitted 128/10 = 12 and bound the entire fleet there -- a tenfold
over-reservation sourced from a price list. The asymmetry is the tell:
memory_max on this same row is derived from measured floor-job cgroup peaks,
so one axis was grounded in our own instrument and its sibling in a vendor
catalog for other silicon.

Replaced by an authored provisioning reserve of one core per 3 GiB, which
says what it is rather than borrowing evidence it does not have. It stays far
above the single core the workload needs so parallel link/codegen phases keep
headroom. cores_per_slot 10 -> 9, CPU admits 14, committed width becomes
min(memory 17, cpu 14) = 14.

Dissolve-on: a measured floor-job CPU demand series from the same cgroup
instrument that produced the memory figure (cpu.stat rather than memory.peak).

The orphaned reading function and its now-dead imports are deleted; the survey
itself stays consumed by gunbc.memory_provisioning.

Published by deep-owl-720 (convergence lane, item F). This commit was authored on 2026-09-19 in the main checkout and never pushed. It is published unchanged so it can be reviewed at an exact head. D (cpu_quota) derives from the resulting cores_per_slot.

🤖 Generated with Claude Code

[gunbai-bot]

Verified against head 06c6ef0. Both findings in review 68159 are correct: w_live_ratio_resolves_to_the_vendors_decimal_gigabytes still asserts 3000000000 while the function now returns 3221225472, and the reason: row still describes cores_per_slot 10 and the fleet committing 36.

I'm deliberately not fixing them yet. The independent source review of this head is also on SOURCE HOLD, for a prior reason: the authored 1-core-per-3-GiB reserve is a temporary substitute on its own stated terms (it names its own dissolve-on). Under DESIGN §5's scaffold doctrine that needs an explicit operator verdict before it can be introduced, and a stated dissolution condition doesn't supply one. That review also asked that the witness literal NOT be edited to turn CI green before the policy is decided, because that would make the test a change detector. The operator has been asked to choose between (a) a scoped CPU allocation policy they approve, and (b) keeping the current authority (width 12) until measured cpu.stat demand exists. The witness, the authority row and the placement/conservation claims will be migrated together once that decision is made. Until then this PR is not merge-ready.

— sent from deep-owl-720

[gunbai-bot]

CI failure on 06c6ef0 investigated. required-witnesses-build fails in the generated-artifact phase: provisioning/{srv1,srv3,srv4}/gunbc-ghrunner.sudoers drifted. That's a direct consequence of the width moving 12 -> 14 (the sudoers files enumerate the runner units), and the committed projections weren't regenerated. It's the same unmigrated-evidence gap as review 68159, and it's also a live-host consequence: new sudoers rows would be granted for units 13-14 on each host. I'm deliberately not regenerating while the CPU policy decision is pending with the operator; the regeneration, witness and authority row move together once it's decided. The PR stays on hold.

— sent from deep-owl-720

[gunbai-bot]

Verified review 68200 against the current head a0138f5. All three findings are correct: the reserve is declared as a bare Int where ByteSize is the modeled carrier; the reason: authority row is stale (it still says census-sourced, cores_per_slot 10, and CPU admits 12); and MemoryPerCoreUnresolved has become unreachable, so its refusal controls prove nothing.

Also noting: ci auto-heal pushed a0138f5 to regenerate the sudoers projections (CPUQuota=900%, new srv1-13/srv1-14 rows). That is the regeneration I deliberately held back. It's harmless while the PR is unmerged, but it doesn't make the PR ready: the head now carries sudoers grants for a width nobody has approved.

The PR stays on hold. The independent source review has it on SOURCE HOLD because it introduces a temporary authored reserve without an operator verdict (DESIGN §5 scaffold doctrine). The operator is choosing between (a) a scoped, approved CPU allocation policy, with the carrier, the authority row, the unreachable-arm controls and the witnesses all migrated together, and (b) keeping the current authority until measured demand exists, which would close this PR. None of these fixes will be pushed before that decision.

— sent from deep-owl-720

[gunbai-bot]

Superseded by #11716, which implements the operator's 2026-09-19 ruling (cores_per_slot = 1 per slot, no CPU quota ceiling). The authored 3 GiB reserve here is withdrawn.

— sent from deep-owl-720