Fixes #14638.

What this PR does

Makes the native-Windows / Git Bash terminal.backend: local path actually work. Currently every terminal() call returns exit_code: 126 with empty output; after this patch, echo hello returns hello, cwd persists across calls, and multi-line stdout is captured.

Root causes (three compounding bugs)

1. select.select does not accept pipe fds on Windows. _drain in base.py hits OSError 10038 on the first iteration and exits without reading stdout → empty output, self.cwd never updated from the __HERMES_CWD__ marker.
2. get_temp_dir() falls back to /tmp. Python on Windows resolves that to C:\tmp (doesn't exist), so _update_cwd's open() silently FileNotFoundErrors.
3. builtin cd 'C:\Users\...' \|\| exit 126 — Git Bash's builtin cd does not accept single-quoted Windows backslash paths. Needs POSIX form (/c/Users/...). This is the direct source of the 126.

Fix

• base.py: Windows branch in _drain uses blocking proc.stdout.read(4096) instead of select.select (Py 3.7+ subprocess on Windows doesn't propagate pipe handles to grandchildren, so EOF arrives promptly).
• local.py: get_temp_dir() returns tempfile.gettempdir().replace('\', '/') on Windows — path valid for both Python and Git Bash.
• local.py: new _win_to_posix_path / _posix_to_win_path helpers. LocalEnvironment._wrap_command is overridden to convert cwd before interpolation; _run_bash converts back for subprocess.Popen(cwd=).

All three are Windows-only branches; non-Windows code paths are untouched.

Verified locally

On Windows 11 + Git for Windows:

TEST 1 echo:  {\"output\": \"hello_from_fork\", \"exit_code\": 0, \"error\": null}
TEST 2 pwd:   {\"output\": \"/c/Users/WIN10/Projects/hermes-agent\", \"exit_code\": 0}
TEST 3 cd:    {\"output\": \"/tmp\", \"exit_code\": 0}
TEST 4 after: {\"output\": \"/tmp\", \"exit_code\": 0}   # cwd persisted

Known gaps (NOT in this PR)

This fixes the core terminal path only. Still broken on Windows/Git Bash:

• pty=True — imports pty / termios which don't exist on Windows.
• Process-tree kill — _kill_process on Windows only proc.terminate()s; backgrounded grandchildren can leak.
• Browser tool WinError 193 — npx.cmd / agent-browser shim launched without shell=True.
• Docker / SSH backend cwd translation on Windows hosts — untested here.

Happy to follow up with separate PRs for any of these.

Scope decision is yours

I realize this might be against current direction — the install docs say "Requires WSL2 on Windows" while the code's _find_bash() still searches C:\Program Files\Git\bin\bash.exe. If Git Bash support was deliberately deprecated, happy to flip this PR into the opposite change instead: delete the Windows branch in _find_bash(), fail loud at init with a clear "install WSL2" message, so users don't waste time debugging mysterious exit-126s.

Either direction is better than the current state (code half-supports Git Bash but silently fails). Let me know which you prefer and I'll adjust.

Why native Git Bash matters (user side, for context): WSL2 carries a ~1–2 GB RAM baseline, conflicts with VirtualBox/Android emulators via Hyper-V, and access to Windows-hosted repos incurs 9p filesystem perf costs. For users on constrained machines (which is the reporter's case), the native path is meaningfully cheaper — if it works.