Fix Muse startup behind Construct PTY

[edwin-zvs]

Summary

• answer live CSI 6n cursor-position queries in the shared PTY runtime
• strip handled queries before emission and persistence so clients cannot double-answer and replay stays inert
• track terminal state and resize it with the child PTY
• preserve partial escape sequences at EOF and document the cross-client terminal-query contract

Root cause

Muse emits cursor-position queries during interactive startup and waits for replies before drawing. Construct passed those bytes through but its native TUI did not answer them. Muse retried every two seconds, then exited cleanly after six seconds, leaving the session blank and closed.

Handling the query in the shared live PTY runtime makes startup independent of whether the native TUI, web UI, a remote client, or no client is attached.

Verification

• cargo test -p construct-protocol --features pty adapter::pty::tests — 5 passed
• cargo test -p construct-adapter-muse — 6 passed
• env -u NO_COLOR cargo test --workspace — passed
• cargo build — passed
• installed Muse end-to-end: detached session sef21973cd6fa47958a07b6f61ce1410d remained running, accepted construct send, and returned echo: Reply exactly: muse-cpr-send
• confirmed handled cursor-query bytes were absent from persisted PTY output

No visual recording: this is terminal protocol plumbing, and the detached installed-Muse end-to-end check exercises the failing path directly.