[Feature]: Inline Markdown editor with local save-back-to-file

[Hederstedt]

What feature would you like to see?

Add an inline Markdown editor with local "save back to file" support

Currently MarkView is view-only. The raw view (Ctrl+Shift+M) shows the source in a read-only

, but there's no way to make a quick edit without leaving the browser, opening the .md file in a separate editor, saving, and re-loading the tab.

I'd like to add an edit mode that turns the rendered/raw view into an editable text area, plus a Save action. The goal is the small, common case: spot a typo or tweak a sentence while reading, fix it in place, done.
Proposed UX:
A new "Edit" toggle in the existing ActionButtons menu (and a keyboard shortcut), mirroring how RawToggle already works.

Edit mode shows an editable markdown source; toggling back re-renders live.

A Save action that writes the edited markdown back to disk locally — no servers, no cloud, consistent with the privacy-first model.

I'm happy to implement this and open a PR — opening this issue first per CONTRIBUTING to align on scope and the save strategy before writing code.
Why is this needed?
When reading a local .md file in MarkView (e.g. file:///C:/Users/.../notes.md), fixing even a one-word typo currently means: leave MarkView → open the file in another editor → edit → save → switch back → reload. For the frequent "read and lightly correct" workflow that's a lot of friction.
An inline edit + save keeps the user in the tool they're already reading in. It stays fully local (no external services), so it fits the open-source edition's privacy-first principles.
Additional context
The hard part is "save", not the editor. A content script cannot write to the filesystem — knowing the path from the file:// URL does not grant write access; that's an intentional browser security boundary. So the save path needs a deliberate design. Options, roughly best→heaviest:
A. File System Access API + persisted handle (recommended) — first save: user picks/confirms the file → we get a FileSystemFileHandle, stored in IndexedDB. Subsequent saves to the same file become one click + a permission re-prompt. Closest thing to "save to the same place" without installing anything. Caveat: a handle can't be derived from the file:// URL (by design), so the file must be pointed out once; file:// availability of the API should be verified per browser.

B. chrome.downloads with a Save-As dialog — robust, but can't target the original folder automatically (downloads are rooted in the Downloads dir; no arbitrary absolute path). A dialog every time.

C. Native messaging host — the only way to silently overwrite the exact path, but requires installing a local helper (registry + executable). Out of scope for a lightweight viewer, noted only for completeness.

D. Download / copy-to-clipboard — always works (incl. https:// files); natural automatic fallback when A isn't available.

Proposed plan: build around A as the primary path with D as automatic fallback. No new heavy permissions; no external services.
Implementation fit: this can closely follow the existing RawToggle pattern (toggle via ActionButtons + keyboard shortcut + custom events), so it stays consistent with current architecture and the "core, lightweight, no-framework" constraints.
Open questions for maintainers:
Is an editor in scope for the open-source edition, or is it reserved for PRO?

Preferred save strategy (A/B/D) for a first version?

OK to add the downloads permission if fallback D is included?