bug: Read truncation can split Unicode surrogate pairs

Description

The legacy Read tool and the paged Core reader truncate long lines at 2,000 UTF-16 code units. For valid UTF-8 text, this can leave half of an emoji or another supplementary character at the end of the returned prefix. Encoding that result as UTF-8 produces a replacement character. The original file is unchanged.

Steps to reproduce

Create a text file with Bun:

await Bun.write("unicode-boundary.txt", "a".repeat(1999) + "😀tail\nnext")

Read it with the legacy tool using { filePath: "/absolute/path/unicode-boundary.txt", limit: 1 }, or the Core tool using { path: "/absolute/path/unicode-boundary.txt", limit: 1 }.

Expected: 1,999 a characters followed by the existing line-truncation marker, omitting the emoji that cannot fit. Actual: the prefix also contains an unpaired high surrogate. The legacy output, preview, and display text all receive it. An emoji entirely within the limit should remain intact.

Core enters this line-limited path for files over 50 KiB or explicit pagination; the legacy tool also truncates long lines during its default read.

OpenCode version

Source checkout 5cf9f517cfec3ef68d3e68a12a6a4b3163947f44 (1.18.28); both truncation sites are still present in upstream dev at 5b1e31988ed74b821b3a7ca6647188446992aafc.

Operating System

macOS arm64, Bun 1.3.14.