Avoid panic when truncating non-ASCII Strato responses for logging

[huxint]

Summary

The parse-error paths in fetch_following_list and fetch_user_metadata build a log preview with &text[..text.len().min(300)]. Indexing a str at a fixed byte offset panics if the offset falls inside a multi-byte UTF-8 character, so a malformed-but-non-ASCII response crashes the task from inside its own error-logging path.

Root cause

thunder/strato_client.rs:157 and :227. Response bodies routinely contain non-ASCII data (user display names), so byte 300 landing mid-character is realistic whenever the parse-error branch is reached.

Severity is limited in this snapshot: fetch_user_metadata currently has no caller, and fetch_following_list is only reached for debug requests with an empty following list — so this is a hardening fix for code that is more exposed wherever these clients are used elsewhere.

Fix

Add preview_for_log, which truncates at the nearest char boundary at or below 300 bytes. Output is unchanged for ASCII and short responses.

Verification

• thunder/ ships no Cargo manifest, so the crate cannot be compiled from this snapshot; the helper uses only std str methods and rustfmt parses the file cleanly.
• I verified the helper as a standalone test binary: the original expression panics on a 299-ASCII-bytes-plus-emoji input (via catch_unwind); the fixed version backs up to byte 299, matches the original output on ASCII, short, and exactly-300-byte inputs, and never panics across all emoji straddle offsets.