fix: support Windows preset launchers

[jamiechicago312]

Summary

• choose the preset venv entrypoint from the host OS so native Windows uses .venv/Scripts/python.exe
• make preset setup.sh fall back to python or py -3 when python3 is unavailable
• add regression coverage for both behaviors

Why this is required for native Windows local mode

On native Windows, preset runs can fail before the prompt even starts when the generated automation assumes Unix/POSIX launcher conventions:

• .venv/bin/python main.py does not exist on a Windows virtualenv (.venv\Scripts\python.exe does)
• many Windows installs expose python and/or py, but not a python3 shim

That failure path surfaces as exit_code=127 (command not found), which in turn can trip stale-run recovery and create duplicate recovery runs. For Slack Channel Monitor, that can mean two "On it!" links / two conversations for one Slack message.

Dependency / downstream impact

This is the permanent upstream fix for one of the Windows blockers currently being shimmed in OpenHands/agent-canvas#1257.

I verified that by reviewing tools/automation-sitecustomize/sitecustomize.py in #1257: it currently patches OpenHands/automation at dev time to add exactly these two fallbacks:

• python3 -> python -> py -3
• .venv/bin/python -> .venv/Scripts/python.exe

So:

• #1257 can work today because it carries a Windows-only compatibility shim
• this PR is still required for first-class/native support in OpenHands/automation itself and to remove that shim debt from the downstream stack

Testing

• uv run pytest tests/test_preset_router.py -q
• uv run ruff check openhands/automation/preset_router.py tests/test_preset_router.py
• bash -n openhands/automation/presets/prompt/setup.sh
• bash -n openhands/automation/presets/plugin/setup.sh

Closes #171.

This PR description was updated by an AI agent (OpenHands) on behalf of the user.