bug: saving after editing expanded includes can inline composed content into the parent file

[chaoxu]

Summary

Editing text inside an expanded ::: {.include} region can cause Save to write the flattened composed document back into the parent file, destroying the original include directive structure.

Why this is a bug

The editor expands include blocks directly into the live CM6 document for display and editing, but the save path still writes the current editor document back to the main file unchanged.

The current flow is:

1. useEditorDocumentServices.initializeView() expands includes and dispatches the expanded text into the editor.
2. useEditor suppresses onDocChange only for that initial programmatic replacement.
3. The first real user edit inside the expanded region updates session liveDocs with the flattened document text.
4. useEditorSession.saveCurrentDocument() writes that flattened text to the parent file.

The reverse mapping helpers already exist in SourceMap, but they are not used when saving.

Impact

A user can unintentionally rewrite the parent markdown file so that:

• ::: {.include} blocks disappear
• included content is inlined into the parent file
• the document structure on disk no longer matches the intended modular source layout

This is data corruption, not just a UI mismatch.

Affected code

• src/app/hooks/use-editor-document-services.ts
• src/app/hooks/use-editor.ts
• src/app/hooks/use-editor-session.ts
• src/app/source-map.ts

Suggested direction

Do not save the composed editor document directly when includes are expanded.

Possible fixes:

• keep the editable document model rooted in the main file and render include content without replacing the saved source document, or
• on save, reconstruct the main file with include references restored and decompose included-region edits back into their owning files before writing

At minimum, the save path needs to become source-map-aware before expanded includes are treated as editable source.