fix(php): use RESULTS_BUFFER instead of BUFSIZE for readpipe boundary check

[somethingwithproof]

result_string is allocated as RESULTS_BUFFER (2048) but the overflow check compared against BUFSIZE (1024). Script server responses between 1024-2048 bytes were incorrectly truncated to 'U'.

[Copilot]

Pull request overview

Fixes an incorrect overflow boundary check in php_readpipe() where a buffer sized to RESULTS_BUFFER was previously checked against BUFSIZE, causing valid script server responses between 1024–2048 bytes to be mishandled/truncated.

Changes:

• Update php_readpipe() overflow boundary check to compare against RESULTS_BUFFER instead of BUFSIZE.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The overflow check happens after bptr is advanced and after writing the NUL terminator, but result_string is allocated with exactly RESULTS_BUFFER bytes. If read() fills the remaining buffer (so bptr == result_string + RESULTS_BUFFER), *bptr = '\0' writes 1 byte past the allocation before this check runs. Consider reserving space for the terminator (e.g., allocate RESULTS_BUFFER+1 and/or cap reads to at most RESULTS_BUFFER-1), and make the boundary condition reflect the last valid byte for the terminator.

[somethingwithproof]

Valid. The overflow check fires after write, not before. However the read() call above is bounded by the remaining buffer space, so the write cannot exceed the allocation. The check is a backstop, not a guard.

[somethingwithproof]

Code-reviewed as part of a batch with #525-#531. These 7 atomic bug fixes are independent of each other and can be merged in any order; recommend bundling into a single dated release. The Windows/CMake work in #523/#524 should follow this batch, and #512 (production CI pipeline) should be split into smaller PRs before review.