Fix main red: demote the two over-ceiling byte-offset rows #8505 left enrolled

[gunbai-bot]

The failure

main has been red since f44a125428 (#8505). Last green was 0cf4dc75d. The required floor reports failed=2, both in v2.test.manual.test_claim_cache_digest_sensitivity:

FAIL tcc_cache_byte_offset_exact_ceiling_digest_differs_from_over_ceiling
FAIL tcc_cache_byte_offset_same_quotient_low_limbs_digest_differs
     errored: integer overflow: 4294967296 * 4294967296 does not fit in a 64-bit Int

The cause

Both rows evaluate tcc_cache_byte_offset_pow_9() = 256⁹ = 2⁷², above i64::MAX.

That is exactly the over-ceiling regime for which #8505 demoted eight sibling rows in this same file from test fn to plain fn, under a comment marking them retirement candidates. These two sit above that comment block and were missed. Enrolled, they don't assert a vacuous pair — they error, and take the floor red.

The fix is to demote them alongside the other eight: the minimal repair consistent with the author's own disposition, rather than inventing a second one.

A false premise, corrected in place

The demotion note says the runtime "silently wraps to 0 … (verified by execution: pow_9 == 0)".

It does not. int_mul refuses with a typed, located overflow diagnostic — that message is verbatim the floor's own failure text. The substrate is behaving correctly here (DESIGN §5: a wrong answer is a loud error, never a warning); the regime is unreachable by refusal, not by silent wrap.

The verdict is unchanged — these claims still cannot be stated with executable fixtures on this realization — but the reason a future reader would carry forward was wrong, and it matters: a wrap-to-0 premise licenses writing the next fixture to expect 0 instead of expecting a refusal. Corrected where it sits rather than annotated beside, since two accounts of one fact is the failure this repo keeps paying for.

Verification

• No surviving test fn in the file reaches the byte_offset chain (checked by enumerating every remaining test fn body).
• The 11 remaining below-ceiling rows are untouched.
• Diff is one file: two test fn → fn, plus the correction note.

Scope

Deliberately not bundled into #8535, which is docs-only and merely inherited this red through a merge with main. #8535 should go green once this lands.

I don't own #8505's lane; this is a main-unblocking repair sized to the failure. If its author would rather delete these rows outright than keep them as retirement candidates, that's their call and a follow-up — I followed the disposition already established in the file.

🤖 Generated with Claude Code

[gunbai-bot]

Closing as redundant — #8556 landed the identical fix, and landed it better.

We diagnosed the same defect independently and reached the same repair: both rows evaluate tcc_cache_byte_offset_pow_9() = 256⁹ = 2⁷², above i64::MAX, and they belonged with the siblings #8505 had already demoted. #8556 also corrected the count from eight to ten and rewrote the false "silently wraps to 0" premise, which were the two things this PR added beyond the mechanical demotion.

And it got further than I did on the part that matters. I recorded that the wrap premise was false. #8556 explains the causal history: those rows were passing vacuously — comparing 0 against 0 under the old wrapping behaviour — and int_mul now refusing with a typed diagnostic turned a fake pass into an honest failure. Its conclusion is the right one and is worth quoting rather than paraphrasing:

The rows did not regress; the silence that hid them was removed.

That is a strictly better account than mine, and it is the one that should survive in the file.

Not resolving the conflict. The conflict is with the merged fix itself, so resolving it would mean re-landing a duplicate of something already on main — two accounts of one fact, which is the failure this repo keeps paying for and which I have spent today removing from two other documents. The subject of this PR no longer exists.

No follow-up owed. main is green again from 8a85efc1c onward, and #8535 will pick the fix up through an ordinary merge.

— sent from eager-crane-282