[Feature Request] Follow the app's theme automatically when a matching preview theme exists

[akurach]

Since #46, the preview ships 10 built-in themes selectable via extension.markeditPreview.themeName. However, the preview theme is static: switching the app/editor theme leaves the preview on whatever themeName says, so Editor and Preview modes look mismatched unless the user manually keeps the setting in sync.

Now that the theme infrastructure exists, would you consider a lightweight auto-follow?

• When the app's current theme has a same-named (or explicitly mapped) preview theme — e.g. Dracula, Solarized, Rose Pine, Xcode, Synthwave '84, Winter Is Coming — pick it automatically.
• Fall back to the current themeName behavior when there is no match.
• Perhaps behind an opt-in like "themeName": "auto", so existing configurations are unaffected.

Unlike #13 (which predated the built-in themes and would have required porting every app theme), this is just a name-mapping between two lists that already exist. Happy to contribute a PR if the approach sounds acceptable.

[akurach]

Looked into feasibility; sharing findings.

It's implementable with what already exists:

• MarkEdit.editorConfig.theme carries the app's current theme name, and it stays live: the bootstrap assigns editorConfig: window.config (same reference), and setTheme() mutates window.config.theme.
• The name mapping is trivial and complete: stripping the -light/-dark/-dawn suffix from every app theme name (github-light, xcode-dark, rose-pine-dawn, …) yields exactly the 10 preview theme names. 100% coverage, no new CSS needed.

Two details worth handling:

1. There's no theme-change notification for extensions, so the preview would re-read editorConfig.theme on each render/open; an already-open pane restyles on the next update rather than instantly.
2. The app theme pins its variant (xcode-dark is dark regardless of the system scheme), while the preview currently picks light/dark by color scheme. The suffix should therefore pin the preview variant too — e.g. xcode-dark → theme xcode, forced dark — otherwise a dark editor next to a light preview is possible.

One caveat supporting the opt-in design: themes installed as extensions (via markedit-theming) override visuals while editorConfig.theme still reports the underlying built-in name, so "themeName": "auto" would mismatch for those users — another reason to keep the default behavior unchanged.

[cyanzhong]

This sounds reasonable, I don't remember why it wasn't covered in #46 but if it is feasible, feel free to open a PR.

Thanks.