[Bug] /copy command corrupts UTF-8 text to latin-1 mojibake in clipboard write

Bug Description
/copy corrupts non-ASCII text (UTF-8 → latin-1 mojibake) in 2.1.169 — regression. Repro: /copy any text with chars ≥ U+0080 (e.g. "configuración → §"), paste → mojibake. ASCII is unaffected. Env: WSL2 + VS Code integrated terminal (TERM_PROGRAM=vscode), DISPLAY=:0, WAYLAND_DISPLAY=wayland-0; only xclip on PATH (no wl-copy/xsel); locale C.UTF-8. Evidence the bug is in the clipboard WRITE encoding, not the source: - /copy's own dump file (/tmp/claude-*/copy.txt) is correct UTF-8 (verified by hexdump: ó=c3 b3, §=c2 a7, →=e2 86 92). - Re-publishing that same file via xclip -selection clipboard -t UTF8_STRING pastes correctly → corruption is introduced when /copy writes the clipboard (likely OSC-52 base64 built from a latin1 string, or xclip invoked without the UTF8_STRING target). Confirmed regression: a long-lived session on the prior build copies the same text cleanly; only 2.1.169 mangles it.

Environment Info

• Platform: linux
• Terminal: vscode
• Version: 2.1.168
• Feedback ID: 7b04a4f7-48dc-4465-a962-d5a43ff1b662

Errors

[]