The wall-fill stall's trigger fired without the class climbing, so the trigger is what changes

[gunbai-bot]

gunbc.guarantee_stall.wall_deadline_shared_fill_attribution_stall declared its next-rung trigger
as an OBSERVATION conjoined with ONE MECHANISM CHANGE: the floor's ledger reports an
INTERRUPTED-BEFORE-VERDICT row whose clock is Wall, at which point the wall deadline must read a
fill-netted clock. Both halves happened today --
carrier_ref_hand_authored_census_is_zero_refusals was refused on the Wall clock at main
9b341e1 against a 29.7s resolve_declaration_ref_over fill it did not cause, and gunbc#10748
netted the clock one commit later -- and the invalid state is exactly as writable as it was. That
is DESIGN.md section 4b(2)'s named defect: a trigger naming less than the capability it restores
is satisfied while the capability stays dead.

THE ROW IS NOT RETIRED AND THE RUNG DOES NOT MOVE. Retiring on a fired trigger while the ceiling
is unreached is rung inflation, which section 4b(1) prices as worse than sitting low because an
inflated class never ranks for climbing again. A netted clock makes the misattribution not happen;
it does not make it unwritable. And rung 2 is not reached either: #10748's discriminating RED is a
v1-compiler lib test, and gunbc.rung_drop rust_unit_tests_off_the_merge_path records that no
CI step runs that command, so nothing on the acceptance path keeps the two arms netting tomorrow.
#10748 is recorded as progress against the subject, at rung 1, with the population unchanged.

THE NEW TRIGGER IS AT CAPABILITY GRAIN and says what it is not sufficient for, because that is the
half the old one omitted: an enforced budget's baseline must be DERIVED from the carrier that
measures the fill, so a raw Instant or a raw thread-CPU read is not a value an arm site can
supply. Both arms netting correctly -- what #10748 delivered -- explicitly does not satisfy it.

AND THE ROW'S OWN JUSTIFICATION DID NOT HOLD, which is recorded in the row rather than filed as a
new class. It argued it existed "because a comment beside the code would go stale on the day the
population changes while this row cannot"; it went stale on the same commit as the
budgeted_cpu_nanos comment it was written to outlive (corrected in gunbc#10764), by the same
mechanism -- nothing executing reads either one. Declaring the fact as data bought COUNTABILITY,
not enforcement. Both halves have existing homes: the fired-but-dead trigger is the class filed in
gunbc#10755, and countability-without-enforcement is
gunbc.recurring_failure_mode.a_written_row_is_not_a_firing_mechanism. The receipt lands on that
row with the ledger's next regeneration rather than here, so this diff carries one subject.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CQyej6wA7GiSibWkkjMsro