hermes - 💡(How to fix) Fix TUI /copy uses remote native clipboard instead of OSC52 in SSH/tmux sessions [1 pull requests]

Summary

Hermes TUI /copy can report success without updating the user's local clipboard in remote terminal chains such as:

local iTerm2 → ssh → tmux → sudo/su to another user → hermes --tui

In the tested setup:

Air iTerm2 → ssh serpo@studio → tmux as serpo → sudo -u shag with TMUX/SSH env preserved → hermes --tui

manual DCS-passthrough OSC52 updated the Air clipboard correctly, but Hermes /copy needed two changes to work reliably:

1. Assistant-message /copy should prefer terminal OSC52 when running in a remote/tmux/screen session, rather than first trying the remote native clipboard backend (pbcopy on macOS).
2. writeOsc52Clipboard() should wrap writes for multiplexers, matching the existing read-query path. Raw OSC52 through tmux did not reach the local clipboard; DCS passthrough did.

Reproduction notes

Observed with iTerm2 clipboard access enabled and tmux allow-passthrough on.

Layer tests:

• local iTerm2 raw OSC52: works
• SSH without tmux raw OSC52: works
• tmux raw OSC52: does not update local clipboard
• tmux DCS passthrough OSC52: works
• Hermes /copy 1 before the fix: can report copied to clipboard or emit raw OSC52 without updating local clipboard
• Hermes /copy 1 after the fix: reports sent OSC52 copy sequence (terminal support required) and updates local clipboard with clean assistant text

Expected behavior

In remote terminal chains, /copy should place clean assistant response text into the user's local terminal clipboard, not the remote host/user pasteboard.