fix(computer-use): enforce JSON line UTF-8 byte limit

[liuxiaocs7]

Summary

Measure the accumulated stdio JSON-line tail in UTF-8 bytes before comparing it with maxBufferBytes. This prevents multibyte executor output from retaining substantially more memory than the negotiated byte budget.

Add focused regression coverage for an over-limit multibyte tail, an exact-limit multibyte tail, and unchanged ASCII behavior across chunks.

Fixes #4952

Verification

• npm --workspace @maka/computer-use run build — passed
• node --test packages/computer-use/dist/__tests__/stdio-json-rpc.test.js — 3/3 passed
• npm --workspace @maka/computer-use run test:dist — 117/117 passed
• npm --workspace @maka/computer-use run typecheck — passed
• npm run build — passed
• npm run typecheck — passed after rebuilding workspace declaration output
• npm run lint — passed
• npm run format:check — passed
• npm test — the changed tests passed, but the repository-wide parallel run failed in unrelated timing-sensitive PTY/process tests under load (packages/eval lifecycle cancellation, Runtime PTY ordering/rendering, and three existing maka-cu process timeout cases). The affected @maka/computer-use suite passed when rerun independently.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope:

Codex diagnosed the byte/code-unit mismatch, implemented the fix, added regression tests, and ran verification.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

Reviewed exact head 185bcf66903e22040d2ee31a13afefb94ff0c368. I found no P0-P2 issues.

The defect is independently reproducible on the production framing path: the service derives this limit from the executor's negotiated byte budget, while the old comparison counted JavaScript UTF-16 code units. At the real 4 MiB floor, a CJK tail of 4,194,306 UTF-8 bytes was previously retained without overflow; this head reports overflow as intended.

The change is localized to the shared JSON-line framing authority and preserves the exact-limit and ASCII boundaries. The focused tests pass 3/3, the Computer Use suite passes 117/117, and changing the implementation back to string.length makes the over-limit multibyte regression fail. The current-main synthetic merge is clean, and the exact-head hosted test check is successful.

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[Astro-Han]

Reviewed exact head 185bcf66903e22040d2ee31a13afefb94ff0c368.

The shared JSON-line decoder now measures the accumulated string with Buffer.byteLength(rest, 'utf8') at packages/computer-use/src/stdio-json-rpc.ts:73-76, matching the byte-cap contract while preserving the existing overflow callback, returned tail, parsing, and lifecycle behavior. The production maka-cu caller passes UTF-8 strings from child.stdout.setEncoding('utf8') through the negotiated stdoutBufferCap() at packages/computer-use/src/maka-cu-service.ts:519-553.

The new tests cover a multibyte tail above the limit, the exact six-byte UTF-8 boundary, and the existing ASCII boundary at packages/computer-use/src/__tests__/stdio-json-rpc.test.ts:25-69. I found no P0-P3 correctness, protocol, or resource-boundary issue. The exact-head label and test checks passed; the merge-tree against current origin/main and diff check are clean, and changed-file Biome checking passed. The local worktree has no usable TypeScript compiler or built dist, so I did not independently run package tests or typecheck locally, and no native executor/Electron smoke was run.

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.