stdio.ts/ReadBuffer retains consumed input and copies the next stdio chunk

Finding: In @modelcontextprotocol/sdk 1.29.0 (and the v1.x and main code at the commits cited in the issue), ReadBuffer.readMessage() in shared/stdio.ts advances with subarray(index + 1). When the newline is the final byte, this leaves an empty Buffer view that still references the original backing allocation. The next append also takes the Buffer.concat path, because an empty Buffer is truthy. This is an external report; KFA did not reproduce it. Source: https://github.com/modelcontextprotocol/typescript-sdk/issues/2536 The reporter says the effect is bounded, not an unbounded leak. It raises idle external memory and peak memory, and adds copying, in long-lived stdio processes, especially with large messages or memory limits (issue body, same URL). A second user reported measurements on 1.29.0 with Node v26.10.0 on macOS arm64. After consuming an ordinary JSON-RPC frame with an 8 MiB payload, the buffer had 0 unread bytes but 8,388,657 backing bytes still referenced, and clear() released it (https://github.com/modelcontextprotocol/typescript-sdk/issues/2536#issuecomment-5959531339). That user's controls on the installed class and on a main-branch class showed the allocation retained after repeated GC. A private-copy control that cleared an empty remainder returned ArrayBuffer usage to baseline across ten cases. This tested the proposed small change, not the full #2540 checkout. Boundary: the same commenter found that an 8 MiB frame in 64 KiB chunks still caused 128 concat calls, about 549 MB of cumulative output, with or without the empty-buffer change. They describe this as cumulative copying, not simultaneous resident memory, and as a separate cost. Status: the issue proposes setting the buffer to undefined when the remainder is empty and keeping non-empty remainders unchanged. Contributors say they plan or are preparing PRs (a v1.x fix; #2540 targets main) (https://github.com/modelcontextprotocol/typescript-sdk/issues/2536#issuecomment-5960039678). The supplied thread shows no merged fix, no release and no maintainer confirmation, so the fix is unmerged and unreleased as far as the sources show. Limitations: all evidence comes from the issue author and one commenter, not from KFA reproduction. The commenter did not attribute their OOM to this defect and did not measure live payload sizes. Middle comments may be missing from the supplied thread.