Windows: Environment variables not inherited when launched via plugin, causing opener/preview failures

Hi @mikavilpas, thank you for maintaining this excellent plugin! I'm encountering an issue on Windows where Yazi behaves differently when launched from Neovim via `yazi.nvim` compared to launching it directly in my terminal (WezTerm). ## 🔍 Problem Description When opening Yazi through the plugin in Neovim, I receive an error message (see screenshot below) and several features fail to work, including: - Bulk rename (`no text opener found`) <img width="358" height="121" alt="Image" src="https://github.com/user-attachments/assets/d5420739-af47-472e-87ea-a4ea09189f9e" /> - Image & PDF previews However, running `yazi` directly in WezTerm with the **exact same configuration** works flawlessly. All previews and openers function as expected. ## 🐛 Steps to Reproduce 1. Open Neovim on Windows(win 10,) 2. Trigger Yazi via the plugin (e.g., `:Yazi` or configured keybinding) 3. Observe the error prompt on startup 4. Attempt to preview an image/PDF → fails 5. Compare with running `yazi` directly in WezTerm → works perfectly ## 💻 Environment - **OS:** Windows 10 - **Neovim:** `nvim 0.11.7` - **Plugin:** `yazi.nvim` v13.1.5 - **Yazi:** ` v13.1.5` - **Terminal:** WezTerm、WindowsTerminal - **Shell:** PowerShell ## 🤔 Suspected Root Cause I believe this is related to **environment variable inheritance on Windows**. It appears that when `yazi.nvim` spawns the Yazi process via `jobstart()`/`termopen()`, it doesn't fully inherit the Windows user `PATH` or other environment variables (like `$EDITOR`). This would explain why: - Terminal launches work (shell loads user `PATH` & variables) - Neovim launches fail (GUI/independent process uses a limited base environment) - Openers and previewers that rely on external binaries (`code`, `ffmpeg`, `image previewers`, etc.) cannot be resolved ## ❓ Questions 1. Is there a recommended way to ensure Windows environment variables are properly passed to Yazi when using this plugin? 2. Would adding explicit `env` forwarding in the plugin's job configuration help, or is this a known Windows-specific limitation? Thank you for your time and for this fantastic plugin! I'm happy to test patches or provide additional logs if needed.