fix: skip bash syntax validation on Windows - #30

Confirming this PR is needed, and reporting a second Windows blocker that sits immediately behind it.

Environment: Windows Server 2016, Python 3.13, Git Bash, environment.shell set to C:\Program Files\Git\bin\bash.exe.

With this PR applied, _validate_bash_command no longer raises FileNotFoundError — but every command then fails at execution with returncode 127:

/usr/bin/bash: Files\Git\bin\bash.exe: No such file or directory
The agent loops on this until it hits step_limit.

Cause. environments/local_workspace.py runs commands as:

subprocess.run(command, shell=True, executable=self.config.shell, ...)
On Windows, subprocess with shell=True builds the command line as /c "". /c is cmd.exe syntax; bash expects -c. Minimal repro, using an 8.3 short path to rule out the space in Program Files:

python -c "import subprocess;print(subprocess.run('ls', shell=True,
executable=r'C:\PROGRA~1\Git\bin\bash.exe', capture_output=True, text=True))"

CompletedProcess(args='ls', returncode=126, stdout='', stderr='/c: /c: Is a directory\n')
bash resolves /c as the MSYS path to the C:\ drive root. So executable= cannot drive bash on Windows at all, independently of the syntax check this PR fixes.

Suggested fix — invoke the shell directly instead of via shell=True:

result = subprocess.run(
[self.config.shell, "-c", command],
text=True,
...
This does not change POSIX behaviour. CPython's POSIX _execute_child already does exactly this:

if shell:
args = [unix_shell, "-c"] + args
if executable:
args[0] = executable
It also removes the need for short paths, since list2cmdline quotes arguments containing spaces.

With this PR plus that change, the harness runs end-to-end on Windows and completes tasks normally.

Happy to open a separate PR for the local_workspace.py change if that's preferred.