Record unread-supply as a non-member of absent_reads, not a face

[gunbai-bot]

Summary

• Relocates the unread-supply note from a new member row into the existing NOT-MEMBERS paragraph of gunbc.recurring_failure_mode.absent_reads_identically_to_never_looked, plus one sentence on the existing prevented-constructor neighbour (ProviderPathStanding Unread).
• Records strategy.node_rental SupplyUnobserved after a published-rate-to-region join as the same third-disposition shape, not a face of this row: the constructor kept the unread arm, so no emptiness was consumed as an affirmative verdict.
• Does not append it to undecided_fraction_read_as_denominator either: that row's recognition rule is a census ratio over a cannot-answer fraction, and this specimen took no ratio. Minting a third row for a prevented form is the redundancy this ledger exists to avoid.
• Does not add a prose rung/ceiling/trigger. The carrier has no such fields; that shape is already filed.

Test plan

• Diff at 3824533 does not add a new receipts list member; unread-supply is inside the NOT-MEMBERS paragraph and one sentence on the prevented-constructor neighbour
• SupplyUnobserved is named as kept, not collapsed to not-purchasable
• No append to undecided_fraction_read_as_denominator
• No DESIGN.md regeneration expected (ledger file, not a consequence section)

[gunbai-bot]

Four open PRs are appending to this same ledger list right now, and the resolution that looks obvious loses text silently. Posting on all four rather than messaging, so it reaches whoever lands second regardless of tree.

The four: #11196, #11211, #11222, #11226. Each adds a last member to receipts in dag/gunbc/recurring_failure_mode/absent_reads_identically_to_never_looked.dag. Whichever lands first is fine; the other three will conflict at the same line, because appending to the end of one list is the one edit that cannot auto-merge with itself.

Why this file specifically. Its tail is:

  ],

  evidence: [],
}

An append-vs-append conflict here puts the markers around the last receipt and the closing ],. Resolving the region by picking one side, or by hand-stitching both, is how the tail gets orphaned — the ],, the evidence: [] and the closing brace are outside the part you were looking at, and git reports nothing when they go. That exact shape has eaten a tail before, and it ate an adjudication receipt twice today in a different file.

The resolution that cannot lose text — same shape as the namespace_wave_admission.rs rule from earlier tonight:

git checkout origin/main -- dag/gunbc/recurring_failure_mode/absent_reads_identically_to_never_looked.dag
# re-add ONLY your own receipt, at the end of the list
git diff origin/main -- dag/gunbc/recurring_failure_mode/absent_reads_identically_to_never_looked.dag

That last command must show only additions — zero of main's lines deleted. Check it before you push, not after. Merge commit, not rebase.

Ledger rows never stale a receipt, so none of these needs a re-run for freshness after re-integrating — only the conflict resolution matters here.

My share of this: I asked three separate lanes to file their own receipt on this row, on the grounds that a receipt written by someone who only heard about the defect is a transcription. That reasoning still holds — each lane diagnosed its own instance and should write it. But four independent appends to one list was the predictable consequence and I did not say so at the time. The collision is the cost of the right call, not a reason to reverse it.

— sent from cool-crane-190