Editor: preview toggle unmounts the gallery mid-upload, and a draft save can outlive publish

[feruzm]

Three pre-existing issues surfaced while reviewing #3526. None is caused by that PR, and none was worth widening it, but all three are real.

Preview toggle unmounts the uploads gallery mid-upload

markdownEditorView renders the toolbar only in the non-preview branch, so toggling preview unmounts EditorToolbar and with it UploadsGalleryModal, while any upload in flight keeps running in the old instance's closure.

Consequences:

• The completion bypasses the typing gate, because the old instance's isEditingRef is frozen. fix(editor): image upload stuck on Uploading..., corrupted typing, image in the wrong place #3526 makes that insert rather than strand (stranding was worse), but it can still rewrite the body while the user is typing after returning from preview.
• The new instance recovers rival placeholder names from the body, but a name recovered that way is never cleared, since the completion resolves in the old instance. That can leave otherPending over-reporting and disable the optional placeholder repair. It fails safe (an insert is dropped rather than misplaced), but it is untidy.
• The paramFiles effect re-runs on remount, so a shared file can be uploaded and inserted twice.

The fix is to stop unmounting the upload machinery on a preview toggle: keep the gallery mounted and hide it, or hoist upload state above the preview branch.

A remote draft save can complete after publish

_saveDraftToDB re-checks _isPublished immediately before updateDraft/addDraft (added in #3526), but the request itself is still in flight across the publish. If a save started just before the user published, addDraft can create a server draft after publication, and the publish path only clears the local cache when there is no draftId, so the stray draft survives.

Options: serialize the save with publication, or delete the draft returned once _isPublished is set. Needs care, since it deletes something the user explicitly asked to save.

Uploads are identified only by filename

MediaInsertData carries no id, so an upload is matched to its ![](Uploading... name) placeholder by filename alone. Two uploads sharing a name are therefore indistinguishable: prepareInsertDispatch collapses them in its Set, the placeholder text is byte-identical, and applyMediaLink replaces the first match. If the second upload settles first, the two urls end up swapped.

Both images still land, so this is a wrong-order bug rather than a data-loss one, which is why it was left alone. The fix is a stable per-upload id on MediaInsertData, matched on instead of the filename. That type is a contract shared by the editor, the quick-post modal and the video uploader, so the change touches all three consumers.