fix(xcrush): off-by-one in forward match loop causes panic during compression

[Copilot]

The XCRUSH find_match_length forward loop used fm > buf_end instead of fm >= buf_end, allowing it to read one byte past the current block boundary (buf[history_offset + src_size]). This inflated match_length beyond the block, causing current_offset > self.history_offset in generate_output, and an integer underflow panic at:

let trailing_len = self.history_offset - current_offset; // underflow

LibFuzzer reports this as a crash (exit status 77). The fuzzer corpus input that triggers it is 131 bytes with algo_byte & 0x03 == 3 (Rdp61/XCRUSH) and sufficient repeated-byte content to produce within-block chunk matches on the first call.

Changes

• xcrush/mod.rs — find_match_length: Change termination condition fm > buf_end → fm >= buf_end so forward matching stops at the block boundary.
• xcrush/mod.rs — generate_output: Add debug_assert! + defensive Err return before the subtraction as belt-and-suspenders protection against future regressions in match generation.
• Regression test: Add the fuzzer crash input as a binary fixture under test_data/fuzz_regression/bulk_round_trip/ so check_bulk_round_trip catches any recurrence.

[Greg Lamberson (glamberson)]

Neat.