fix: prevent panic when filtered PTY output exceeds read buffer

[ttak0422]

Problem

TerminalOutputFilter carries partial control sequences across reads in its pending buffer, so a single filter() call can emit more bytes than the chunk it consumed (carried-over pending + current chunk). read_pty() copied the filtered bytes back into the fixed 64KiB read buffer:

let filtered_len = filtered.len();
buf[..filtered_len].copy_from_slice(&filtered); // panics when filtered_len > buf.len()

Reproduction path: an OSC 52 clipboard payload larger than the read buffer accumulates in pending across reads; when its terminator arrives on a full 64KiB read, filtered_len > buf.len() and the daemon panics — killing the session.

Fix

read_pty() now appends filtered output to a caller-provided Vec (pending_pty_output in the server drain loop) instead of writing back into the read buffer, and returns the raw byte count so EOF detection (Ok(0)) is unchanged. The type change removes the overflow class entirely — no size assumption left to violate.

Added terminal_output_filter_output_can_exceed_input_chunk to pin the invariant that motivated the API shape.

Verification

• cargo test: 31 passed
• cargo clippy --all-targets: clean

🤖 Generated with Claude Code