[Bug] "auto" theme does not follow system color scheme changes

[alloutflo]

Problem

When VS Code follows the operating system appearance, the WYSIWYG editor does not switch between light and dark themes even though markdownWysiwyg.colorTheme is set to "auto".

Closing and reopening the Markdown document does not help. The VS Code workbench changes to the correct appearance, while the WYSIWYG editor remains dark.

Environment

• WYSIWYG Markdown Editor: 0.3.2
• VS Code: 1.131.0 (arm64)
• macOS: 26.5.1
• window.autoDetectColorScheme: true
• workbench.preferredLightColorTheme: "GitHub Light Default"
• workbench.preferredDarkColorTheme: "GitHub Dark Default"
• markdownWysiwyg.colorTheme: "auto"

Steps to reproduce

1. Set macOS appearance to Dark.
2. Open a Markdown file in the WYSIWYG editor.
3. Change macOS appearance to Light.
4. Observe that the VS Code workbench switches to the light theme.
5. Observe that the WYSIWYG editor remains dark.
6. Close and reopen the Markdown document; it still remains dark.

The same issue occurs in the opposite direction.

Expected behavior

With markdownWysiwyg.colorTheme: "auto", the WYSIWYG editor should follow the currently active VS Code color theme whenever the system appearance changes.

Root cause

In MarkdownEditorProvider._getThemeColors(), the "auto" branch reads:

currentThemeLabel = vscode.workspace
    .getConfiguration()
    .get<string>("workbench.colorTheme");

When window.autoDetectColorScheme is enabled, VS Code changes vscode.window.activeColorTheme, but the configured workbench.colorTheme value can remain the dark theme (for example, "GitHub Dark Default").

Therefore, onDidChangeActiveColorTheme fires correctly, but applyThemeToAll() resolves and reapplies the stale configured dark theme.

Suggested fix

For "auto", use the CSS variables that VS Code already injects into the webview:

private async _getThemeColors(
    themeId: string,
): Promise<Record<string, string>> {
    if (themeId === "auto") {
        return getAutoThemeColors();
    }

    // Existing custom and explicitly selected theme handling...
}

getAutoThemeColors() already returns an empty object for this purpose, and the webview's setTheme handler removes previously applied overrides before relying on the injected --vscode-* variables.

An alternative would be to resolve workbench.preferredLightColorTheme / workbench.preferredDarkColorTheme based on vscode.window.activeColorTheme.kind, but using the injected variables appears simpler and also preserves the exact active theme colors.