feat(tui): collapse large pastes to a marker, expandable in place

[Max17190]

Why

A pasted log or minified blob splices verbatim into the draft, burying it and leaving the six-row composer scrolling through content the user never meant to edit. Comparable frontends that shipped collapse without a way back generated the field's angriest issue threads, so collapse and expand ship together.

Summary

A paste at ten lines or a thousand characters collapses to a numbered [pasted #N: ...] marker. The bytes rejoin the draft for every whole-text reader (submit, queueing, history), so a marker never leaves the composer. ctrl+o with the cursor on a marker splices the bytes back in place for editing, outranking the last-tool-block expansion only in that position; an edited marker stops matching and stays literal. Small pastes splice exactly as before.

Test Plan

• large_paste_collapses_to_a_marker_and_reads_back_expanded, small_pastes_splice_literally, a_single_line_blob_collapses_on_the_char_bound, expand_paste_at_cursor_splices_the_bytes_back_for_editing (incl. cursor-off-marker refusal and idempotence), an_edited_marker_never_expands.
• Collapse and expansion each shown red with their mechanism neutered; existing paste-splice and CRLF tests unaffected. Workspace tests and clippy clean.

Greptile Summary

This update collapses large terminal pastes into editable markers while preserving their original content for submission, adds cursor-targeted marker expansion, improves approved-file recovery commands, and refines terminal replay, notification, and unread-message behavior. Focused composer checks confirmed that duplicate marker text does not deliver hidden content twice and that marker-like text embedded in an earlier paste does not interfere with a later paste. Ledger output also retained the correct approved object-to-file mappings after bound files changed.

Confidence Score: 5/5

No blocking failure remains; the exercised composer and ledger recovery flows behaved as intended.

No accepted blocking findings remain.

T-Rex Logs

What T-Rex did

• I built and ran the OpenMax CLI against the approved external-tool manifest binding (runner.sh and helper.py) and captured the ledger output before and after rewriting both live files; the results show each stored object is paired with its original bound path and the restore targets remain derived from the authenticated approval data.
• I reproduced the baseline sequential marker-replacement behavior and ran the focused Rust composer regression tests; the tests completed successfully, and the current composer delivers hidden content once for a typed duplicate marker and restores a later paste at its real marker while leaving embedded marker-like text literal.
• I validated multi-file tool restore consistency by comparing multi-file logs; the before log shows the initial approved ledger footer with two bound-file restore commands and the after log shows mappings after changes, proving paths come from the approved manifest rather than live content.
• I ran the baseline legacy sequential replacement, observed the former failures, and confirmed the current focused Rust tests pass; the harness source and command outputs are uploaded for review.

_{Ran code and verified through T-Rex}

_{Reviews (4): Last reviewed commit: "fix(tui): paste expansion never searches..." | Re-trigger Greptile}