Fix allocator capacity bounds checking and tracking in Buf32

[matteoldani]

This PR fixes a memory safety vulnerability in Buf32 that causes Undefined Behavior when interacting with global allocators that over-provision memory (such as jemalloc ).

When Buf32 initially allocates memory via Vec::with_capacity() , the global allocator often returns a buffer slightly larger than requested to align with memory chunk boundaries. Previously, Buf32 mistakenly stored the requested capacity rather than the actual capacity returned by the allocator.

When the buffer was later deallocated or resized using Vec::from_raw_parts , it passed this smaller, incorrect capacity back to the global allocator. Providing a mismatched layout size back to the allocator violates Vec 's API invariants and is
Undefined Behavior, which can result in immediate segmentation faults or silent heap corruption.

Changes:

• Buf32::with_capacity now queries vec.capacity() to determine the true allocated layout size.
• The capacity calculation translates this back into byte capacity by explicitly subtracting the first H header block.
• Adds a bounds check against u32::MAX to explicitly panic and prevent 32-bit truncation if an allocation happens to unexpectedly exceed u32::MAX bytes.

Resolves #751

[matteoldani]

I've realized that the grow function suffered of the same issue

[simonwuelker]

We have bytes_to_vec_capacity, can we add a vec_capacity_to_bytes to avoid duplicating this code?

[matteoldani]

Done, thanks for the suggestions

[simonwuelker]

nit: Use the OFLOW constant.

[matteoldani]

Done

[simonwuelker]

Thanks