[kunpai]

Write BFINAL with the caller's bit pointer, as C's AddBit does

Problem

ZopfliDeflate and ZopfliDeflatePart (C, Rust) take the caller's bit pointer bp. C's comment says bp is always in 0..7, and so does the port's safety note, but neither side checks it. The first bit a block writes is BFINAL (C, Rust), and the two sides write it differently when bp is 8 or more:

• C's AddBit appends a byte only when bp is 0, ORs bit << *bp into the last byte, and only then masks bp to 0..7. For bp from 8 to 31 the shifted bit falls outside the byte, so BFINAL is lost, and a multiple of 8 appends no byte.
• The port masks bp first, so BFINAL lands at bit bp & 7, and a multiple of 8 starts a new byte.

Every bit after BFINAL is the same on both sides, since (bp + 1) & 7 is ((bp & 7) + 1) & 7. For example, ZopfliDeflate with btype = 1, final = 2^31-1, bp = 115, an empty input and one output byte 0xb7:

	C	Rust
output	b7 00 (BFINAL dropped)	bf 00 (BFINAL at bit 3)

With final = 0 both sides write a 0 bit, so they agree.

Question

Which behaviour do we want: C's or the Rust port's? Specifically, when bp is 8 or more, should the block's BFINAL bit be shifted by the caller's bp, so that it is dropped and a multiple of 8 starts no new byte (like the C source), or should bp be masked to 0..7 before anything is written (like the Rust port)?

This PR implements C's behaviour.

Fix

• deflate_helper keeps the caller's bp: let old_bp = *bp in place of *bp & 7. A bp that is a multiple of 8 then continues the caller's last byte, as in C.
• add_bit shifts as C does: the shift is done on a u32, as C's bit << *bp is done on an int, so a bit shifted past bit 7 is dropped. bp is advanced with wrapping_add, as C's int arithmetic does for bp 255.

-    out[last_idx] |= bit << *bp;
-    *bp = (*bp + 1) & 7;
+    out[last_idx] |= (bit as u32).wrapping_shl(*bp as u32) as u8;
+    *bp = bp.wrapping_add(1) & 7;

-    let old_bp = *bp & 7;
+    let old_bp = *bp;

Replayed before and after (x86-64), on the campaigns' records:

	C	Rust main	Rust patched
ZopfliDeflate, btype = 1, bp 115 (the example)	b7 00	bf 00	b7 00
ZopfliDeflate, btype = 1, bp 246, a 2-byte input	output	different output	C's output
ZopfliDeflatePart, btype = 1, bp 244, a 2-byte input	output	different output	C's output

The .outsize records the campaigns found have an out-of-range btype as well as a bp of 8 or more. With this PR and #212, the ZopfliDeflate ones (bp 196, 99 and 64) agree with C too.

Downstream check. The normal path is untouched (bp in 0..7): ZopfliGzipCompress on the repository's README gives the same 831-byte stream from the port before and after this patch, and gzip.decompress restores the file.

Notes for review:

• For bp 32 or more, C's shift is undefined behaviour. On x86-64, where the campaigns ran, the count is taken mod 32, so for bp 32..39 (mod 32) the bit lands at bit bp mod 32. wrapping_shl does the same, so this patch reproduces x86-64. Other targets may differ. The patch itself is safe Rust.
• A caller that keeps to the documented 0..7 sees no change.
• One ZopfliDeflatePart record (btype out of range, instart 2^64-1 > inend 0, bp 123) still differs with this PR, Compress an out-of-range btype as a dynamic block, as C does #212 and Read the input the way C does when ZopfliDeflatePart gets instart > inend #216: the port returns without writing. Its dynamic-block path also refuses instart > inend, which Read the input the way C does when ZopfliDeflatePart gets instart > inend #216 does not change.
• The port's tests pass unchanged.