fix(flat): handle multi-byte advance in consClose decoder

[Unisay]

Context

Fix consClose in the Flat decoder so it correctly advances the stream pointer when constructor tag bits + already-used bits span 2+ bytes. Without this, Generic-derived Flat instances of large enums (>256 constructors) corrupt the decoder state during deserialization, consuming all available memory.

Fixes #7542

What went wrong

The Generic-derived decoder uses a ConsState machine for constructor tags. After decoding, consClose advances the byte stream by the number of bits consumed. The problem: it only handled advancing by at most 1 byte. When constructor_bits + usedBits >= 16 (say, a 9-bit constructor tag after 7 bits already consumed in the current byte), usedBits overflowed to 8+, outside the valid range of [0, 7].

Once corrupted, dBool computes 128 >> usedBits as 0, so it always returns False without moving the stream pointer. The Filler decoder reads 0-bits as FillerBit and a 1-bit as FillerEnd, so it just keeps building an infinite chain of FillerBit constructors until memory runs out.

The fix swaps the hand-rolled if/else for divMod, the same pattern dropBits_ already uses 80 lines below in the same file.

Changes

Bug fix:

• consClose in Decoder/Prim.hs: use divMod instead of single-byte advance logic, so any number of bytes is handled correctly

Reproduction test (two new cases in testLargeEnum in Spec.hs):

• Control: 7 Bool fields + E258_256 (8-bit tag), 8+7=15 < 16, works fine
• Bug trigger: 7 Bool fields + E258_258 (9-bit tag), 9+7=16, previously caused infinite loop; protected with 5-second timeout

[effectfully]

Fixing dead code instead of removing it is moronic.

[zliu41]

This doesn't seem correct. I don't know whether endPtr points to end of buffer, or end of buffer + 1, but either way it doesn't seem correct.

In the former case, currPtr s' > endPtr is not an error if usedBits = 0.

In the latter case, currPtr s' == endPtr is an error if usedBits /= 0.

[Unisay]

Good catch, you're right. currPtr > endPtr misses the case where currPtr == endPtr with usedBits > 0, since that state points past the buffer but claims bits remain.

Rewrote consClose to use ensureBits + dropBits_, same pattern dropBits already uses. ensureBits checks (endPtr - currPtr) * 8 - usedBits < n, so the pointer and bit offset are both accounted for.

[Unisay]

Also added a test for this: decoding a 9-bit constructor tag from a 1-byte buffer. It asserts the error is NotEnoughSpace (from consClose via ensureBits), not TooMuchSpace (from strictDecoder catching the bad state after the fact). See 1fed628.

[zliu41]

This should be upstreamed.