Panic when rendering Arabic/RTL text in terminal: byte index not a char boundary

Bug Description

Claude Code panics when rendering Arabic (RTL) text in the terminal. The Rust code is incorrectly slicing UTF-8 strings at byte boundaries instead of character boundaries.

Error Message

thread '<unnamed>' (4673598) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 1 is not a char boundary; it is inside 'ة' (bytes 0..2) of `ة موثقة`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

Context

• The string ة موثقة is part of Arabic text ملاحظة موثقة (meaning "documented observation")
• The character ة (tā' marbūṭa) is a 2-byte UTF-8 character (bytes 0..2)
• The code attempts to slice at byte index 1, which falls inside this multi-byte character

Steps to Reproduce

1. Have a file containing Arabic text (e.g., a TypeScript translations file)
2. Use Claude Code to read or display the file
3. The terminal rendering crashes when trying to display the Arabic content

Root Cause

The terminal text rendering code is using byte indices instead of character indices when slicing strings. In Rust, string slicing must occur at valid UTF-8 character boundaries.

Expected Behavior

Claude Code should correctly handle multi-byte UTF-8 characters (Arabic, Chinese, emoji, etc.) when rendering text in the terminal.

Environment

• Platform: macOS (Darwin 25.0.0)
• Claude Code version: Latest
• File encoding: UTF-8

Suggested Fix

Use character-based indexing (e.g., .chars().take(n)) or ensure byte indices align with character boundaries (e.g., using str::is_char_boundary()) before slicing strings in the terminal rendering code.