Fix packing of unaligned integers, narrow integer widths and exclusive byte ranges

[rudib]

Summary

An oracle-based test sweep of how integer fields are placed in the packed bytes. The core bit placement turned out to be correct, but it uncovered four bugs around it:

• Integers narrower than their native type didn't compile. Integer<T, Bits<N>> was only implemented when N needed exactly size_of::<T>() bytes. That rejected a u32 field in 12 bits, a u16 in 4 bits, or [u32; 4] with element_size_bits="12". Every native type now supports all the widths that fit into it.
• Exclusive byte ranges were one byte short (fixes Derive macro calculates incorrect bit size when using a non-inclusive bytes="x..y" field attribute #107). bytes="0..2" covered only byte 0, and the field's explicit size_bytes was silently ignored, so a u16 was packed into a single byte. A field whose position and size disagree is now a compile error.
• Arrays that don't split evenly into elements are now rejected. Before, the leftover bits were silently ignored, or the derive panicked.
• Fields of 32+ bytes at unaligned offsets lost data. A per-byte mask was computed from a bit count cast to u8, which wrapped. This affected nested structs and large reserved fields.

Tests

• packing_bit_oracle.rs: a bit-by-bit reference implementation. It checks every supported width at offsets 0–7 and 13, for MSB and LSB, signed and unsigned (540 cases). Unpacking is also checked with all surrounding bits set.
• packing_narrow_ints.rs: the same checks for widths stored in wider native types (228 cases).
• packing_arrays_oracle.rs: arrays of unaligned integers (3, 5, 12, 20 and 52 bit elements, and bools) through the new loop-based array codegen, plus large unaligned fields.
• issue_107.rs: regression test for Derive macro calculates incorrect bit size when using a non-inclusive bytes="x..y" field attribute #107.

Behaviour changes

• A field whose bit/byte position and size_bytes/size_bits disagree is now a compile error.
• The layout of LSB integers whose width isn't a multiple of 8 is unchanged. It is now pinned down by the tests.

🤖 Generated with Claude Code