Width chain reads one supplied HostWidthFacts record; placement standing takes it

[gunbai-bot]

Leg 4 of node adhoc-da1df2b9-c50, part (d): the width-chain facts-record refactor, as its own PR, per quiet-stag-623.

Why

The runner width chain in gunbc.runner_slot_allocation looked up each per-host input by HostIdentity at the step that used it. The inputs are: usable RAM, fixed overhead, session reservation, control-plane claim, served-deployment claim, disk, shakedown slot and CPU axis. Usable RAM was read twice on one path. As a result, a claim about the derivation could only reach it through the keyed tables. A host with no rows yet (mtcollins1, before its census receipt) could not be asked about at all, so the leg-4 "placement accepts mtcollins1" witness was unreachable (#13252).

Change

• HostWidthFacts with one producer, host_width_facts(host): every input above, looked up once.
• The width chain is now a set of *_of(f) functions over that record: runner_memory_envelope_of, memory_admitted_width_of, memory_denominator_of, width_axes_of, committed_width_of, derived_runner_slots_of.
• The host-keyed functions stay as f(host) = f_of(host_width_facts(host)). So no consumer changes: gunbc_runner_committed_width, host_memory_admitted_width, host_memory_denominator, host_width_axes, host_runner_memory_envelope_resolution.
• host_runner_memory_envelope and host_runner_memory_envelope_bytes had no callers outside the chain, so both are deleted and replaced by runner_memory_envelope_bytes_of.
• gunbc.ci_runner_placement host_deployment_standing_given(offer, facts, placement) is the standing over a supplied record, and host_deployment_standing supplies the production record.
  • Its session slice comes from the record (session_slice_of).
  • The control-plane claim is still evaluated under the placement argument, because the record holds the default placement.

Every existing host's committed width is unchanged (A/B, same probe, BuildBuddy)

	srv1	srv2	srv3	srv4
main 0a6a6dc	10	unresolved	17	17
this branch 07c05e4	10	unresolved	17	17

At this branch's pre-merge head (07c05e4), these existing claims also evaluated true:

• runner_slot_allocation_committed_widths_are_the_minimum_over_axes, srv2_width_resolves_to_a_typed_refusal_naming_its_denominator, runner_slot_allocation_unknown_host_refuses_a_width
• runner_slot_allocation_cpu_axis_unchanged_for_every_enrolled_host, runner_slot_allocation_RED_no_offer_host_has_no_cpu_width, runner_slot_allocation_wall_holds
• witness_live_plan_is_conservation_sound (the real placement path)

New claims (test.claim.host_width_facts_witness)

• host_width_facts_supplied_record_reproduces_the_keyed_route: the production record, supplied, reproduces the keyed answer for srv1–srv4 and for srv3's placement standing. This runs the real producer.
• host_width_facts_RED_supplied_usable_ram_moves_the_standing: supplying srv3 with unmeasured usable RAM refuses UsableRamUnavailable, and supplying half its RAM gives a strictly smaller width. Neither result is reachable through the keyed tables.

Consumers of the host-keyed functions (unchanged; each now resolves through host_width_facts)

gunbc: build_cache_endpoint_observe, build_cache_instance, ci_runner_placement, fleet_capacity_panel, fleet_converge_plan, fleet_host_budget, fleet_runner_connectivity, host_axis_caps, host_converge, host_converge_slice1, roadmap_dashboard_instance, runner_host_deploy, runner_slot_desired, runner_slot_population_census, runner_slot_provision, runner_slot_retirement, runner_width_transition, recurring_failure_mode (state_space_conflation, a_count_field_whose_subject_drifted_from_its_producer), rung_drop.microvm_shakedown_slot_row_above_fleet_row.
test.claim: build_cache_endpoint_observe, executor_privileged_operation_witness, fleet_capacity_panel, fleet_converge_plan, fleet_show_effective_read, host_allocation_conservation, host_converge_slice1, runner_capacity_plan, runner_host_file_converge, runner_lifecycle, runner_placement, runner_slot_allocation, runner_slot_provision.

Not in this PR

The RAM-backed tmpfs workspace charge inside slot memory, and the mtcollins1 accept witness. Both now have a seam: a HostWidthFacts for mtcollins1 can be supplied once #13252's offer and the census receipt land.

🤖 Generated with Claude Code

[gunbai-bot]

Post-merge (b5391ac) re-run on BuildBuddy: the probe gives srv1=10 srv2=unresolved srv3=17 srv4=17, unchanged from main. host_width_facts_supplied_record_reproduces_the_keyed_route and host_width_facts_RED_supplied_usable_ram_moves_the_standing both evaluated true.

[briansrls]

APPROVE at the REQUESTED exact head b5391ac3d29bbd004756462120a48ccca3d64e1f, against DESIGN.md §§3, 3c, 4b and 5. The PR currently reports a later tip 40158985cc77e87394f06ac55ceb19c83438df9d; this review does not cover that later tree.

Reviewed the four-file refactor against the merged main parent 296061a898b3a79351fd191118dfe0c0dd08e1f8. The host-keyed production entries now obtain one HostWidthFacts and delegate to the value-based computation. The width/minimum arithmetic, unknown-session/CPU refusals, shakedown charge and existing envelope fallback boundary remain unchanged. The placement wrapper derives the facts from its own offer identity; the supplied entry is the calculation seam for controls, not a claim of observed host state. The explicit control-plane placement continues to govern the placement conservation check, while the width facts retain the same default-placement semantics as before.

The real-producer equivalence claim and unmeasured/halved-RAM discriminating control are present. The post-merge BuildBuddy receipt reports srv1=10, srv2=unresolved, srv3=17, srv4=17 and both new claims true; exact-head witnesses run 37202788784 is completed/success. I did not execute local tests.

This approves the facts-record refactor only. It neither supplies mtcollins1's missing census nor establishes its placement acceptance or the separate RAM-backed workspace charge.