fix(tui): handle invisible codepoints when measuring label width - #23377

Issue for this PR

Closes #23376

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes the agent label rendering corruption I reported in #23376.

The TUI's truncate and truncateMiddle helpers in packages/opencode/src/util/locale.ts used str.length to decide whether to truncate. That counts invisible codepoints (U+200B, U+200C, U+200D, U+FEFF) as one UTF 16 code unit each, even though they render as zero columns on screen. When a string fit in real rendered width but exceeded the limit in code unit count, the helper chopped visible letters and appended an ellipsis, producing labels like Sisyphus: ltraworker.

This PR switches the width check and the per character walk to Bun.stringWidth, which is already idiomatic in this repo for cursor math. Examples of existing Bun.stringWidth callers:

1. packages/opencode/src/cli/cmd/tui/component/prompt/autocomplete.tsx:172
2. packages/opencode/src/cli/cmd/tui/component/prompt/autocomplete.tsx:373
3. packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:389

Why it works: Bun.stringWidth reports 0 columns for the four zero width codepoints named above and 2 columns for wide graphemes like emoji, which matches the Unicode spec for terminal rendering width. Using it here makes both helpers correct for any string, not just ASCII.

Input strings without invisible codepoints behave identically to the old implementation. That is covered by the first test case in the new test file.

How did you verify your code works?

Added a new co located test file packages/opencode/src/util/locale.test.ts with 11 cases. Ran it locally:

cd packages/opencode
bun test src/util/locale.test.ts
# 11 pass / 0 fail / 41 expect() calls / 329ms

Test cases covered:

1. Plain ASCII short strings are returned unchanged.
2. A U+200B prefixed string whose rendered width equals the limit is NOT truncated (repro of bug(tui): agent label rendering corrupts when name contains invisible Unicode codepoints #23376).
3. A U+200B prefixed string whose rendered width exceeds the limit gets truncated at the visible boundary.
4. Plain ASCII truncation produces a result of display width equal to the limit and ending in the ellipsis.
5. All four invisible codepoints (U+200B, U+200C, U+200D, U+FEFF) are handled identically.
6. Mixed strings with emoji (width 2), ZWSP, and ASCII truncate at the correct visible boundary.
7. truncateMiddle returns the input unchanged when rendered width is within maxLength.
8. truncateMiddle at exact width with a ZWSP prefix is NOT truncated.
9. truncateMiddle on a long ZWSP bearing string produces startOut + "…" + endOut with correct widths against keepStart and keepEnd.
10. truncateMiddle default maxLength of 35 is preserved.
11. truncateMiddle on plain ASCII returns the same shape as before.

Typecheck note: the monorepo uses bun turbo typecheck. My sandbox could not complete the full workspace install cleanly (bun install stalled on the dep graph in my environment), so I limited automated verification to the targeted test file. The change is scoped to one module with no new imports and no new type surface. Happy to run any additional verification a maintainer wants.

Byte level evidence for the bug is in issue #23376.

Screenshots / recordings

This is not a UI change in the visual sense, but the bug is a visible rendering defect. The simplest reproduction is the hex dump included in issue #23376:

e2 80 8b 53 69 73 79 70 68 75 73 20 3a 20 55 6c 74 72 61 77 6f 72 6b 65 72

That decodes to U+200B followed by Sisyphus : Ultraworker. With the old truncate, feeding that string at len=22 returned "\u200BSisyphus: Ultraworke…" because str.length was 23. With the new truncate, Bun.stringWidth(str) is 22 so the string is returned unchanged. No ellipsis, no chopped letter.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR