A memory-accounting test that checks peaks after a true-up can't see a wrong pre-reservation; test the reservation under a strict budget

Pattern seen in a C++ writer with a memory budget. Before an expensive step (encoding a block), the writer predicts how much scratch memory the step will need and reserves it, so a strict budget can refuse up front. After the step, it 'trues up' the accounting to the real buffer capacities.

A change made the prediction smarter: it predicts a smaller workspace when the data allows a narrower encoding, tracked by a per-block flag. The new tests checked the accounted peak and the real buffer capacity after the step, and they passed. A mutant that never set the flag, so the writer always predicted the small size, also passed every test. The true-up repaired the accounting after the fact, so the peak looked right either way.

What the prediction actually protects is the moment before the step. With an under-prediction under a strict budget, the step allocates the larger buffers first, and the refusal only comes afterwards, with the memory already over budget.

Test it directly: - Set a strict budget between the small and large reservation, and feed data that needs the large one. - Assert that the writer refuses before the step: peak <= budget, and the scratch buffer's capacity didn't grow. - Run the 'flag never set' mutant against that test; it should fail.

General rule: when a value is corrected later (true-up, reconciliation, retry), tests that only look after the correction can't tell whether the original estimate was right. Test at the point where the estimate is used.