CLAUDE_PLUGIN_ROOT path separators stripped on Windows-client + WSL-mounted project (semgrep@2.1.1 MCP fails 100%)

Hitting what looks like the same bug class on this exact combo: Windows-native Claude Code client + WSL-mounted project (cwd = \wsl.localhost\<distro>\home\<user>\projects), plugin installed from the official claude-plugins-official marketplace (semgrep@2.1.1).

The plugin's MCP server (semgrep-guardian) fails to connect 100% of the time (3/3 attempts across separate sessions). From mcp-logs-plugin-semgrep-guardian/*.jsonl:

Server stderr: /bin/bash: C:Usersaleks.claudepluginscacheclaude-plugins-officialsemgrep2.1.1scriptshook.sh: No such file or directory
Connection failed after 227ms: MCP error -32000: Connection closed

The resolved script path has all path separators stripped — C:Usersaleks.claudepluginscacheclaude-plugins-officialsemgrep2.1.1scriptshook.sh instead of C:\Users\...\...\hook.sh — then handed to /bin/bash (a POSIX/WSL shell), which of course can't find it. Looks consistent with the inconsistent-resolution pattern described in this issue (marketplace-source path vs. the agent's actual Bash execution environment).

For comparison, another official plugin (lumen) on the same machine/session connects successfully every time via stdio, so this seems specific to how this particular plugin's hook.sh launcher path gets resolved/passed to Bash, not a blanket WSL-mount failure.

Workaround in the meantime: installed the Semgrep CLI directly inside WSL via pipx (independent of the plugin's MCP mechanism) — works fine for scanning, just without the native Claude Code MCP/hook integration.

Happy to share full log files or test a fix if useful.