fix(ide): resolve Win32 error 193 on Windows and support WSL UNC paths

[EduTiyo]

Summary

Resolves an issue on Windows where attempting to launch an IDE (such as VS Code) fails with "%1 não é um aplicativo Win32 válido. (os error 193)" (ERROR_BAD_EXE_FORMAT), and adds support for UNC / WSL folder paths (\\wsl. localhost\...).

Root Cause

1. Extensionless bash script collision: When searching PATH for code, Windows installations of VS Code include an extensionless POSIX shell script (bin/code for Git Bash/Cygwin) alongside code.cmd. CodeLaunch was picking bin/code and attempting to spawn it via CreateProcessW, which fails because it is not a valid Win32 PE binary.
2. Direct .cmd execution: Spawning .cmd or .bat files directly via Rust's Command::new fails under Windows CreateProcessW without cmd.exe /c.
3. UNC Paths on CMD: Windows cmd.exe does not support UNC paths (\\wsl.localhost\... or \\wsl$\...) with cd /d.

Changes

• Windows CLI Resolution (vscode/mod.rs):
  • Updated resolve_cli_path on Windows to check for valid executable extensions (.exe, .cmd, .bat) instead of accepting extensionless files.
  • Prioritized direct executable paths (Code.exe, Cursor.exe, etc.) in known_candidates and user_candidates.
• Safe Command Invocation (vscode/mod.rs):
  • Wrapped non-.exe targets (e.g. .cmd, .bat or fallback aliases) in cmd.exe /c with CREATE_NO_WINDOW flag.
• UNC & WSL Compatibility (terminal/mod.rs & vscode/mod.rs):
  • Updated resolve_folder_path to treat UNC prefixes (\\ and //) as absolute paths across platforms.
  • Used pushd instead of cd /d in generated Windows terminal scripts when pointing to UNC / WSL paths.

Verification

• All 37 unit and integration tests passing (cargo test).
• Frontend build check passed (npm run build).
• Added unit tests for UNC path terminal generation and launch_command arguments.