fix: generalize Windows remote detection for terminal commands

[shanevcantwell]

Summary

• Broadens the Windows-with-remote check in runTerminalCommand.ts from WSL-only (remoteName === "wsl") to all non-local remotes (!["", "local"].includes(remoteName))
• When a Windows host connects to any remote workspace (Dev Container, SSH, Codespaces, etc.), terminal commands now correctly fall back to ide.runCommand() instead of trying to spawn powershell.exe
• Follows the same pattern established in PR fix: use ide.runCommand when Windows host connects to WSL #9679 (WSL terminal fix, merged in v1.8.0)

Context

The ENABLED_FOR_REMOTES list already includes dev-container, devcontainer, ssh-remote, attached-container, codespaces, and tunnel — but the guard only excluded WSL from direct exec. Any other remote type on a Windows host would enter the direct spawn path and fail with ENOENT because powershell.exe args target the wrong platform.

Fixes #10007
Related: #10067, #9812, #8732

Test plan

• Verify terminal tool works on Windows host → WSL remote (existing behavior preserved)
• Verify terminal tool works on Windows host → Dev Container (no longer ENOENT)
• Verify terminal tool works on local Windows (direct exec still used)
• Verify terminal tool works on native Linux/macOS (no change)

🤖 Generated with Claude Code

---

Summary by cubic

Generalized Windows remote detection in runTerminalCommand to handle all non-local remotes. On Windows with a remote workspace, terminal commands now use ide.runCommand instead of spawning powershell, preventing ENOENT errors across Dev Containers, SSH, Codespaces, etc.

• Bug Fixes
  • Detect any non-local remote on Windows and route commands through VS Code to run in the remote environment.
  • Preserve direct spawn on local Windows; no changes on macOS/Linux.

^{Written for commit b7c2b4f. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file