fix(arrow-buffer): preserve bits outside the requested range in in-place bitwise ops

[haohuaijin]

Which issue does this PR close?

No dedicated issue — found while implementing #10425, whose optimization is the first caller to depend on the behaviour fixed here. Happy to file one if you'd prefer it tracked separately.

Rationale for this change

apply_bitwise_binary_op and apply_bitwise_unary_op are built around the invariant that only the bits in offset_in_bits..offset_in_bits + len_in_bits are modified — the helpers implementing it (align_to_byte, set_remainder_bits, handle_mutable_buffer_remainder_unary) all say so in their doc comments. Two paths didn't honour it:

1. align_to_byte ignored len_in_bits, writing every bit from bit_offset to the byte boundary. If the range started and ended inside the same non-byte-aligned byte, the trailing bits were overwritten with op applied to padding:

let mut left = vec![0b11111111u8, 0b11111111u8];
apply_bitwise_binary_op(&mut left, 1, &[0u8, 0u8], 0, 1, |a, b| a & b);
// expected [0b11111101, 0b11111111], got [0b00000001, 0b11111111]

2. set_remainder_bits zeroed the boundary byte's out-of-range bits, because it read that byte into the low bits of a u64 and masked it with !((1 << remainder_len) - 1). Once the remainder spanned more than one byte, the mask selected nothing. This hit any length leaving a remainder of 9..63 bits that isn't a multiple of 8.

No existing caller was affected, which is why it went unnoticed: BooleanBufferBuilder::append_packed_range copies with |_a, b| b into capacity advance() just zeroed, and the BooleanBuffer/BooleanArray in-place paths run only on uniquely owned buffers and re-wrap with the original offset/length. So the out-of-range bits were either already zero or unobservable.

What changes are included in this PR?

• align_to_byte takes len_in_bits and masks its write to bit_offset..bit_offset + min(8 - bit_offset, len_in_bits).
• set_remainder_bits shifts the boundary byte to the position it actually occupies in the word before masking.
• Both public functions now document the preservation guarantee.

Are these changes tested?

Yes. The gap existed because the two shared test helpers only asserted bits inside the operated range. They now also assert every bit outside it is byte-for-byte identical before and after, which retroactively covers all their call sites — that alone caught bug 2 in 11 pre-existing tests. Added test_ops_ending_inside_the_first_partial_byte (sweeps every offset/len pair inside one partial byte, for AND/OR/XOR and NOT) plus minimal regression tests for the two reproducers.

cargo test -p arrow-buffer passes (342 unit + 54 doc), as do arrow-array, arrow and arrow-select. Clippy and fmt clean.

Are there any user-facing changes?

A behaviour change in two public functions, in the direction of the documented intent: bits outside the requested range are no longer clobbered. No signature changes, and no existing caller could observe the old behaviour. The guarantee is now explicit in the rustdoc.

[haohuaijin]

While implementing #10425 I hit corrupted mask tails, and traced it to two bugs in the in-place bitwise helpers — both write outside offset..offset+len, which they're documented not to do:

• align_to_byte ignored len_in_bits, so when the range started and ended inside one non-byte-aligned byte, it overwrote the rest of that byte.
• set_remainder_bits read the boundary byte into the low bits of a u64 before masking, so once the remainder spanned more than one byte its out-of-range bits were zeroed instead of preserved.

cc @alamb