fix(api/protocol): correct improper message payload data truncation

[djrobx]

What changed

Uses the MsgSize supplied by an OmniLogic multi-part lead message to trim reassembled response data precisely. It also removes the rstrip(b"\x00") call before zlib decompression.

Why

The previous heuristic could remove a legitimate trailing zero from a compressed stream's zlib trailer and make zlib.decompress() raise Error -5 while decompressing data: incomplete or truncated stream. The controller already reports the exact message boundary, so there is no need to guess by removing zero bytes.

zlib.decompress() tolerates trailing protocol padding after a complete stream while continuing to reject a genuinely truncated stream.

Validation

• Captured a live controller response: its declared MsgSize exactly matched the reassembled compressed response length.
• Added an end-to-end regression test for a compressed stream whose valid trailer ends in 0x00, followed by protocol padding.
• pytest -q tests (full suite)
• Ruff lint and format checks

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[djrobx]

This is a Codex generated PR to address
#152

I happened to encounter the -5 condition that some others have run into.

Codex first gave a "fallback" code change that dropped down to a streaming Zlib when -5 was found that worked, but I pressed it to find a cleaner solution. Then it found MsgSize in the header, which I think is the proper fix. But, feel free to reject and re-implement as you see fit. :)

[cryptk]

This looks pretty sane, good catch! I'll try and find some time soon to get a new version of the library released and the HA integration updated.