fix: UTF-8 boundary safety, scroll-to-bottom on reattach, tmux/dtach session persistence

[shockstricken]

Summary

Three independent fixes for stability and display issues observed when running the web-terminal plugin behind a CloudCLI host. All are opt-in or backward-compatible.

1. UTF-8 byte-boundary safety in the pty pipeline (src/server.ts)

node-pty was emitting onData chunks as strings. When the underlying read crossed the middle of a multi-byte codepoint (common with emoji, box-drawing borders, CJK), the chunk was split mid-byte and forwarded as malformed UTF-8. xterm.js then rendered the well-known smeared-border / wrong-width-character glitch.

This switches node-pty to encoding: null (raw Buffer chunks) and routes them through a per-session TextDecoder with {stream: true}. Trailing incomplete bytes are buffered until the next chunk, so what we send over the WebSocket always contains only complete codepoints.

2. Scroll-to-bottom on tab show, attach, and reconnect (src/index.ts)

Reopening a tab — or reconnecting after a disconnect — left the viewport wherever the user had last scrolled, so the prompt was often off-screen and the tab appeared frozen.

show(), attachTo(), and the 'ready' (reconnected) message handler now each call terminal.scrollToBottom() after the fit, so the user always lands at the current prompt without losing scrollback history.

3. Optional tmux / dtach session persistence (src/server.ts)

New env var WEB_TERMINAL_SESSION_BACKEND:

Value	Behavior
`none` (default)	One pty per WebSocket, original behavior.
`tmux`	Wraps shell in `tmux -L web -u new-session -A -s `. Browser refresh reattaches instead of SIGHUPing the running program.
`dtach`	Wraps shell in `dtach -A -z`. Lighter than tmux; same survival semantics.

Companion vars `WEB_TERMINAL_SESSION_NAME` and `WEB_TERMINAL_DTACH_SOCKET` tune the session/socket identifier.

This lets hosts that ship `tmux` or `dtach` give users long-running `claude` / `codex` / `gemini` sessions that survive browser refresh and intermittent network drops without any client-side changes.

Test plan

• `npm install && npm run build` succeeds (verified locally; `tsc --noEmit` and full emit both clean)
• In a host without the env var set, behavior matches main (one pty per WS, SIGHUP on close)
• With `WEB_TERMINAL_SESSION_BACKEND=tmux`, opening two browser tabs to the same host attaches to the same shell; refreshing one keeps the other intact
• Renders emoji / box-drawing borders / CJK characters cleanly when the pty stream spans chunk boundaries
• Closing and reopening a tab lands at the bottom of the buffer

Notes

• `package.json` and `package-lock.json` intentionally unchanged.
• No new runtime dependencies. `tmux` and `dtach` are runtime-resolved on the host PATH only when the env var is set.
• The local `PtyProcess.onData` interface was widened to `string | Buffer` to match `node-pty`'s actual runtime behavior in raw mode.

[Snailflyer]

The tmux/dtach persistence option is the right direction for long-running Claude/Codex/Gemini sessions, but I would test one layer above "reattach works".

Opening two tabs and refreshing one proves the process survives. The user-facing contract also needs to prove the reattached terminal is still the live write target:

• backend (tmux/dtach) and session name
• PTY or pane generation
• tab/client id
• output cursor before input
• tiny input sent after reconnect
• output cursor after input
• result: reattached_live_session, visible_buffer_only, new_pty_created, wrong_session_name, or input_not_consumed

Faryo has the same invariant from the mobile/browser side: the control surface is only complete when the original live tmux-backed session advances, not when the UI reconnects or the bridge accepts input. Reference GIF: https://github.com/Snailflyer/faryo/releases/download/v1.0.7/faryo-public-redacted-same-session-handoff-walkthrough-20260528-0120.gif