fix(ui/channels): avoid UTF-8 char-boundary panics in text truncation

[NiuBlibing]

Problem

dashboard::truncate sliced &first_line[..max] at a raw byte index. When max landed inside a multi-byte character it panicked:

panicked at apps/zerocode/src/dashboard.rs:2082:37:
end byte index 40 is not a char boundary; it is inside '列' (bytes 39..42)
of `用户询问桌面文件列表，助手列出了桌面上的文件夹和文件，包括名称和大小。`

A repo-wide sweep for the same unguarded byte-slice pattern found two more sites with the identical bug (all other slice sites are already guarded via is_char_boundary / char_indices().nth() / find() offsets):

• linkedin: &text[..200] when building the image-generation prompt
• bluesky: &message.content[..297] — additionally compared byte .len() against what the comment documents as a 300-character (grapheme) limit, so multi-byte content both mis-triggered and panicked

Fix

All three now use chars().count() / chars().take(n), which is char-boundary safe and matches the intended character-based semantics.

Notes / scope

• LinkedIn: the 200 is not a platform limit — it only trims text inside an internal image prompt. Character-based is the natural reading.
• Bluesky: the canonical limit is 300 graphemes (+3000 bytes) per the atproto app.bsky.feed.post lexicon. chars() (codepoints) is panic-safe and exact for ASCII/CJK, but slightly conservative for ZWJ/skin-tone emoji. Fully exact grapheme truncation would require adding unicode-segmentation (not currently a dependency); left out of this panic fix.

Testing

cargo check -p zeroclaw-tools -p zeroclaw-channels -p zerocode passes.