Restore image attachments when replaying prompt history

[yxlyx]

Migrated from: https://github.com/yxlyx/lawplain/issues/62

Problem

In the TUI/composer, pressing the up arrow restores the previous prompt text from history. If that previous prompt included an image attachment, history replay currently restores only the literal [Image] placeholder text. Resending then sends a text-only prompt with no actual image, which is misleading and loses important context.

Expected behavior

When navigating prompt history with the up/down arrows:

• A previous prompt with image attachments should restore both the text and the original image attachment(s).
• Resending the restored prompt should include the image payload, not just [Image] text.
• If image replay is not supported, the UI/API should clearly reject or warn instead of silently sending [Image] as plain text.

Observed / likely root cause

The Ask/TUI history path appears to be text-only:

• AskAgent.tsx stores messages/history as text / question strings.
• /api/ask accepts only question, cite, and kind.
• ask-history.ts persists only the text question.
• Up-arrow history restoration calls setInput(historyItem.question) and has no attachment state to restore.

So multimodal prompts are flattened to text before reaching history.

Suggested implementation

Add attachment-aware prompt history end-to-end:

1. Add a shared AskAttachment / history item type, e.g. image MIME type, data URL or stored URL, name/size metadata.
2. Persist attachments alongside ask history, preferably as metadata/URLs rather than large base64 blobs.
3. Return attachments from /api/ask/questions.
4. Accept and validate attachments in /api/ask.
5. Update the agent serialization path to send image parts as actual multimodal content.
6. Update AskAgent.tsx so history navigation stores/restores both:
   • current draft text + draft attachments
   • historical prompt text + historical attachments
7. Avoid de-duping history purely by question text, because the same text may be used with different images.
8. Add a boundary fix: if already at the oldest history item, another Up should not consume the key event unless navigation actually occurred.

Acceptance criteria

• Given a prior prompt like What is shown here? with an image attachment, pressing Up restores the text and shows/restores the image attachment.
• Pressing Enter/resend after restoring sends the image payload to the backend/agent.
• Text-only prompt history continues to work as before.
• Same text with different images remains distinct in history.
• Draft text + draft attachments are restored when navigating back down past the newest history item.
• Tests cover text-only history, image history restoration, resend payload, and unsupported/invalid image validation.

[justrach]

Partially addressed in v0.0.226 (PR #328) - leaving this open.

Landed: A staged image now rides alongside its history entry, so replaying a prompt re-stages the attachment instead of yielding text containing a literal [Image] marker.

Still open: session-level persistence - the image is per-process, so it does not survive a resume.

[justrach]

Partial: a TUI turn that still has the @[path] chip now re-stages the file (a5b4184, PR #507). Session-resume persistence of the pixels is still missing — leaving this open.

[justrach]

Leftover closed in #511: @[path] composer lines stay in input history. The readline image sidecar that restores attachments across resume already shipped on 258.