Panic on UTF-8 multi-byte character boundary when writing Japanese HTML

Bug Description

Claude Code crashes with a Rust panic when writing HTML files containing Japanese text. The error occurs at UTF-8 multi-byte character boundaries.

Error Messages

thread '<unnamed>' panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 11 is not a char boundary; it is inside 'に' (bytes 9..12) of `チーフに。</div>`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
zsh: abort      claude --dangerously-skip-permissions

thread '<unnamed>' panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 14 is not a char boundary; it is inside 'ン' (bytes 12..15) of `るデザイン。</div>`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
zsh: abort      claude --dangerously-skip-permissions

Steps to Reproduce

1. Run claude --dangerously-skip-permissions
2. Ask Claude to write an HTML file containing Japanese text (e.g., a product catalog)
3. The process aborts during the Write operation

Environment

• OS: macOS (Darwin 25.1.0)
• Command: claude --dangerously-skip-permissions

Analysis

The panic occurs in Rust's string slicing code (str::mod.rs:833). The code is attempting to slice a UTF-8 string at a byte index that falls in the middle of a multi-byte character (Japanese hiragana/katakana characters are 3 bytes each in UTF-8).

This suggests the code is using byte indices instead of character indices when processing strings containing non-ASCII characters. The fix would be to use character-aware string operations (e.g., char_indices() or grapheme_indices()) instead of raw byte slicing.