perf(server): avoid base64 fallback for split UTF-8 Flight chunks

[sunflower0305]

Summary

RSC streams can split a valid UTF-8 code point across upstream chunks. createRscEmbedTransform currently decodes each chunk independently with a fatal decoder, so split CJK or emoji bytes are classified as binary and embedded as Base64.

This change keeps one streaming fatal decoder for the embed stream and tracks the raw bytes that the decoder has not released yet. Valid split text stays in text chunks, while invalid binary data and incomplete UTF-8 at EOF still use the existing [3, base64] representation without losing bytes. The decoder is reset after binary fallback so later text can be decoded normally.

This follows the streaming decode used by the Next.js Web Flight transport, with explicit raw-byte retention for lossless error and EOF fallback.

Coverage

• CJK and emoji split at every UTF-8 byte boundary
• invalid binary followed by valid text
• incomplete UTF-8 followed by binary data
• incomplete UTF-8 at EOF
• existing BOM preservation

Application result

Measured on a blog page with 108 RSC chunks:

• Base64 chunks: 54 → 0
• raw RSC script size: -36,108 bytes (-9.1%)
• separately gzipped size: about 36.9 KB smaller

Verification

• vp test run tests/app-ssr-stream.test.ts -t "createRscEmbedTransform raw buffer"
• vp check
• vp run vinext#build

[sunflower0305]

For reference, the measurements in the PR description were collected from this blog page, which produced 108 RSC chunks. The source is available in the blog repository.