Bug: message history restoration corrupts text with attachments #1266

When navigating message history using the "Up" arrow key, messages containing attachments and line breaks become corrupted, resulting in duplicated attachment paths within the text.

Reproducing the issue

Steps to reproduce

1. Start the TUI.
2. Type a message with a line break and an attachment like the example below.
3. Send the message.
4. Press the "Up" arrow key to navigate to the previous message in history.

read this:
@path/to/my/file.txt

Expected result: I expect to see the same text.

Actual result: the message text becomes corrupted with duplicated attachment paths.

read this:
@path/to/m@path/to/my/file.txt

Technical analysis

Disclaimer: the text below was done with the help of an LLM agent.

The issue appears to be in the RestoreFromHistory function in editor.go around line 632. The function:

1. Restores the text via m.textarea.SetValue(entry.Text)
2. Processes attachments by replacing text ranges and inserting attachment objects
3. The range replacement logic may be incorrectly calculating indices when dealing with multi-line text

The problematic code section is:

for _, att := range attachmentsCopy {
    m.textarea.SetCursorColumn(att.StartIndex)
    m.textarea.ReplaceRange(att.StartIndex, att.EndIndex, "")
    m.textarea.InsertAttachment(att)
}

The bug occurs due to a mismatch between how attachment indices are calculated when saving vs. restoring messages:

1. During saving: GetAttachments() calculates absolute positions across the entire text, including newlines
2. During restoration: RestoreFromHistory uses ReplaceRange which operates on individual rows, not accounting for newlines properly

Suggested investigation areas

• Index calculation in RestoreFromHistory when text contains newlines
• Attachment position tracking across multi-line messages
• The interaction between SetValue, ReplaceRange, and InsertAttachment operations