Fix LLP64 bulk length truncation in processBulkItem (#1333)

[LL-V]

Summary

Fixes #1333.

On LLP64 (Windows x64), processBulkItem accumulated bulk size in unsigned long, which can wrap when adding a large long long length so an incomplete bulk is treated as complete.

Changes

• Use size_t for header/item lengths
• Reject lengths that cannot fit in size_t on all platforms
• Overflow-check before completeness test

Test plan

• mingw-w64: incomplete $4294967296\r\nAB no longer calls createString with len=2^32

---

Note

Medium Risk
Touches core RESP bulk parsing used for every $ reply; fixes a real truncation/early-parse issue but behavior changes for out-of-range lengths (now protocol errors instead of silent wrap).

Overview
Fixes a protocol parsing bug in processBulkItem where bulk sizes were accumulated in unsigned long, which on LLP64 (Windows x64) could wrap for large declared lengths and treat an incomplete bulk as fully received (e.g. wrong createString length).

The reader now tracks header and total item size in size_t, rejects bulk lengths that cannot fit in size_t on all platforms (replacing a guard that failed when size_t is 64-bit), overflow-checks hdrlen + len + CRLF before testing buffer completeness, and advances r->pos via the computed itemlen. Nil bulks set itemlen from the header only; createString gets (size_t)len.

^{Reviewed by Cursor Bugbot for commit 48ad634. Bugbot is set up for automated code reviews on this repo. Configure here.}