refactor(tui): extract attachments from document parts in session

[Piyush0049]

Description

This PR resolves a technical debt TODO in pkg/tui/page/chat/chat.go regarding how attachments are retrieved from session history when editing a past message in the TUI.

Previously, extractAttachmentsFromSession relied exclusively on a text-matching fallback ("Contents of <filename>: <dataURL>"). As the codebase has evolved to use MessagePartTypeDocument for structured file attachments, this old extraction logic would fail to properly restore modern attachments to the message editor.

Changes:

• Added proper parsing for chat.MessagePartTypeDocument to safely extract InlineText and InlineData.
• Implemented automatic conversion of binary InlineData payloads into standard data: URIs (base64) so that image attachments render properly in the UI.
• Retained the original "Contents of " string matching strictly as a fallback (legacyPrefix) to ensure backward compatibility with older saved sessions.
• Removed the outdated TODO comment.

Testing

• go build ./pkg/tui/... succeeds.
• go test ./pkg/tui/page/chat/... passes.

[Piyush0049]

I just force-pushed to fix a trailing whitespace error that was failing the linter. The CI should pass now.

[dgageot]

Blocking issue: binary attachments round-trip as raw base64 text in the prompt.

On the resend path, the extracted attachment has FilePath == "" and Content != "", so App.Run → processInlineAttachment (pkg/app/app.go:638-642) embeds the data:<mime>;base64,... URI as literal prompt text inside <attached_file> tags. Nothing downstream parses it back into an image/document part (parseDataURI is only reached via MessagePartTypeImageURL parts). A 3 MB image becomes ~4 MB of base64 text (~1M tokens) — context overflow or a very expensive garbage request; arguably worse than the previous silent drop. It also violates Attachment.Content's documented "raw text content" contract (pkg/tui/messages/session.go:18-21).

Suggested fixes:

• Extend messages.Attachment with MimeType/Data []byte (its doc comment anticipates this) and rebuild a Document part in App.Run, e.g. via chat.ProcessAttachmentWithMetadata; or
• As a safe stopgap, extract only InlineText documents and keep skipping InlineData, with a short comment explaining why.

[dgageot]

See comment above

[Piyush0049]

Thanks for the review. I am working on the suggested fixes.

[Piyush0049]

@dgageot I've implemented the primary suggestion to address the context overflow on the resend path.

Specifically, I:

1. Extended messages.Attachment with MimeType and Data []byte to natively support binary payloads (as the doc comment anticipated).
2. Updated the TUI extraction logic in pkg/tui/page/chat/chat.go to stop base64-encoding InlineData.
3. Added a new branch in App.Run to intercept binary attachments (len(att.Data) > 0) and route them through chat.ProcessAttachmentWithMetadata, safely rebuilding the Document part natively.

Please let me know if this looks good to you.