Draft images/files are lost when switching conversations (only text drafts persist)

[Awenforever]

Summary

Draft images/files pasted into the composer (not yet sent) are silently lost when you switch to another conversation and back. Text drafts survive; attachments do not.

Steps to reproduce

1. Open a conversation and paste an image into the composer (do not send).
2. Switch to another conversation.
3. Switch back to the first conversation.

Expected: the pasted image is still in the composer (or you are warned before it is discarded).
Actual: the image is gone; the text draft (if any) is restored.

Why this happens (from the shipped client source)

• Draft persistence only covers textual content. readConversationDraft(sessionId) in @deepseek-ai/dsh-client-ui-conversation reads localStorage["dsh.conversation.<sessionId>"], and its schema only has text, references, quotes, command — no attachments/attachment ids.
• Draft attachments live in memory only: the Conversation service keeps draftAttachments (image previewUrl object URLs) and fileUploads, and its disposal effect revokes preview URLs, then calls draftAttachments.clear() and fileUploads.set({}) (effect label: conversation draft attachments).
• Switching conversations disposes that session's conversation context, so the in-memory attachments are dropped.

Suggested directions

• Persist draft attachment references (attachment id + name/kind/size) in the draft store and rehydrate on return; keep the blob/upload state in the attachment store so orphan cleanup remains possible.
• If full persistence is not planned, at least show a confirmation/warning when switching away with unsent attachments.
• Expose a per-session draftAttachments count so the shell can warn or badge it.

Environment

• DSH Desktop 0.2.2-rc.1 (Windows 11, Electron 44.7.0, Node 24.21.0)
• Repro is deterministic in the desktop app; same composer in the browser build is expected to behave similarly.

Scope

UX/data-loss gap for a common workflow (collect a few screenshots while reading, then send). Not an attachment-upload failure: sent attachments and stored files work normally.