Reject truncated LiME payloads during block conversion

[Jaeyou PARK (cpuu)]

A truncated LiME record can currently be converted successfully even when its payload is shorter than the range declared in its header.

For example, a record declaring 4096 bytes but containing only 4095 bytes is accepted. The unaligned copy path ignores the byte count returned by std::io::copy, leaving the missing byte as zero in the preallocated buffer. The output therefore contains a zero byte that was not present in the input. An entirely missing payload can also be silently treated as an all-zero block and omitted.

This change checks the copied byte count and returns UnexpectedEof before emitting the incomplete block. It also makes short-read handling consistent with the existing page-aligned path, which uses read_exact.

One parameterized regression test covers empty, one-byte-short, and complete payloads for both LiME and compressed AVML output.

Validation

• Reproduced the regression failure with the original copy behavior and confirmed that it passes with the fix on:
  • x86_64 Linux under WSL2.
  • aarch64 Linux on a Raspberry Pi 4.
• All 30 library tests and both conversion tests pass with --no-default-features --features convert.
• Formatting and strict Clippy checks pass for the tested feature configuration.

The change is limited to the shared unaligned block-copy path.

If accepting truncated payloads is intentional, please let me know. I could not find a documented recovery policy for this behavior, so this PR proposes reporting the incomplete input rather than silently padding it.

[Jaeyou PARK (cpuu)]

@microsoft-github-policy-service agree

[Brian Caswell (demoray)]

Thanks Jaeyou PARK (@cpuu) for finding and fixing the truncated LiME payload issue. While reviewing the other conversion paths, we found the same unchecked-short-read behavior in LiME-to-raw and compressed conversions. Compressed records could also be accepted without their existing length trailer because seeking past EOF succeeds.

We opened #884 to apply the fix consistently across all conversion paths and validate the compressed-length trailer. Your PR provided the original diagnosis and regression case; #884 broadens that work rather than replacing the underlying fix.