Windows: path mangled to Cygwin format (/cygdrive/e/...) causing all MCP tools to fail

Environment

• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell (native, no Cygwin/MSYS2 installed)
• Plugin version: 0.0.40
• Binary: bin/lumen-windows-amd64.exe
• Embedding backend: Ollama at http://localhost:11434
• Embedding model: ordis/jina-embeddings-v2-base-code

What happened

health_check works fine, but index_status and semantic_search fail with a path translation error. The plugin converts a native Windows path into a Cygwin-style path that doesn't exist on the system.

Input path supplied by Claude Code:
e:\depot\TradeAlert

Path the plugin attempts to access:
/cygdrive/e/depot/TradeAlert

Error returned:
ensure fresh: build merkle tree: GetFileAttributesEx /cygdrive/e/depot/TradeAlert: The system cannot find the path specified.

The same error occurs whether the path is passed via the path or cwd parameter, and with both backslash and forward-slash variants.

Steps to reproduce

1. Install Lumen plugin v0.0.40 on Windows 11 (PowerShell, no Cygwin)
2. Confirm Ollama is running and health_check returns OK
3. Call index_status or semantic_search with path: "e:\\depot\\TradeAlert" (any Windows path)
4. Observe the Cygwin path error

Expected behavior

lumen-windows-amd64.exe should accept native Windows paths without translating them to /cygdrive/... format.

Actual behavior

All filesystem-touching MCP tools are broken on Windows — semantic search is completely unavailable.

Start by tracing Windows path handling used by the index_status and semantic_search entry points in bin/lumen-windows-amd64.exe, focusing on how path and cwd values are processed. Reproduce the failure with a native PowerShell path and verify that filesystem-touching MCP tools accept it without converting it to /cygdrive/... format.