fix(tools): translate MSYS paths to Windows-native before shell lint (#66494)

[stantheman0128]

What does this PR do?

On Windows/MSYS the post-write shell linters (node --check, tsc, go vet, rustfmt, py_compile) received the target file path in Git Bash /e/... form. Git Bash single-quotes the {file} argument, which suppresses MSYS POSIX to Windows argument conversion, so native node got /e/project/x.js verbatim and resolved it against the current drive root, producing Cannot find module 'E:\project\Fina\js\models.js' on every .js edit.

The fix reuses the terminal backend's existing _msys_to_windows_path translator, so the automatic lint hands the native toolchain the same Windows-native path the terminal already uses for its cwd. This is exactly the "use the same path-resolution engine as the terminal" approach the issue suggests. Off Windows the path is left untouched, so genuine POSIX names (backslashes and all) still round-trip through the existing shell escaper.

Related Issue

Fixes #66494

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/file_operations.py: in ShellFileOperations._check_lint, translate the file argument via _msys_to_windows_path (then forward-slash form, single-quoted) when _IS_WINDOWS, before substituting into the linter command. Off Windows keeps the previous _escape_shell_arg path.
• tests/tools/test_file_operations_edge_cases.py: add TestCheckLintWindowsNativePath covering both the Windows translation (/e/project/... -> 'E:/project/...', and the raw MSYS path must NOT appear) and the off-Windows passthrough.

How to Test

1. On Windows/MSYS with native node on PATH, edit a .js file through write_file/patch in a project on a non-C: drive (e.g. E:\). Before this change the auto-lint reports Cannot find module 'E:\e\...'; after it, node --check runs against the correct E:/... path.
2. python -m pytest tests/tools/test_file_operations_edge_cases.py -q

Verification output on this branch:

$ python -m pytest tests/tools/test_file_operations_edge_cases.py::TestCheckLintWindowsNativePath -q
..                                                                       [100%]
2 passed in 1.56s

$ python -m pytest tests/tools/test_file_operations_edge_cases.py -q
.....................................                                    [100%]
37 passed in 3.40s

Checklist

Code

• My commit messages follow Conventional Commits (fix(tools):)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've added tests for my changes
• I've tested on my platform: Windows 11 (MSYS/Git Bash)

Documentation & Housekeeping

• Considered cross-platform impact: the translation is gated on _IS_WINDOWS; POSIX behavior is unchanged.

---

Disclosure: this change was prepared with AI assistance (Claude) and reviewed before submission.

[teknium1]

Thanks for tracing the lint invocation through the MSYS path boundary. The local Windows premise remains present on current main: tools/file_tools.py:385 resolves MSYS paths to native paths, while tools/file_operations.py:1771 sends them back through Git-Bash escaping for shell linters.

Problems

• tools/file_operations.py:1782 gates translation only on the host-wide _IS_WINDOWS flag. ShellFileOperations is shared by local and remote backends (tools/file_operations.py:793-799), so a Windows host running a Docker/SSH/Modal/etc. backend can have valid in-backend POSIX /e/... paths rewritten to E:/.... This conflicts with the existing backend-path boundary documented by tests/tools/test_file_tools.py:475-490.
• The added tests mock _exec on an object made with __new__, so they do not exercise the backend distinction.

Suggested changes

• Restrict conversion to LocalEnvironment as well as Windows; tools/file_operations.py:1882-1901 already has an established local-backend gate pattern.
• Add a remote-backend regression test asserting an /e/... path remains POSIX while retaining the local native-path assertion.

Automated hermes-sweeper review.

[teknium1]

_IS_WINDOWS describes the host, not the terminal backend. ShellFileOperations also executes in Docker/SSH/Modal/etc.; on a Windows host this rewrites valid remote Linux /e/... paths to E:/.... Please additionally gate this on LocalEnvironment (the existing _lsp_local_only() helper shows that backend-boundary pattern) and add a remote-backend passthrough test.

[stantheman0128]

Thanks for the catch on the host-vs-backend boundary.

Updated so MSYS lint path translation runs only when the host is Windows and the ops are wired to a LocalEnvironment (same backend check as _lsp_local_only). Docker/SSH/etc. on a Windows host now leave in-backend POSIX paths like /e/... alone.

Also added a remote-backend regression test with a real DockerEnvironment instance (not just a __new__ mock without env), and kept the local native-path assertion.

Verification:

scripts/run_tests.sh tests/tools/test_file_operations_edge_cases.py -q
=== Summary: 1 files, 38 tests passed, 0 failed ===

python scripts/check-windows-footguns.py tools/file_operations.py tests/tools/test_file_operations_edge_cases.py
No Windows footguns found (2 file(s) scanned).