Resolve npm .cmd-shim backends on Windows

[av-frox]

Fixes #1.

What was wrong

resolve_binary() uses shutil.which. Under native Windows Python that walks PATHEXT and returns the .CMD sibling with backslashes:

>>> shutil.which("codex")
'C:\\Users\\<user>\\.npm-global\\codex.CMD'

$ which codex
/c/Users/<user>/.npm-global/codex

The resolved value is consumed by bash in backend_run.sh, and neither half of the existing check can accept it: command -v does not resolve an absolute backslash path, and [[ -x ]] is false because npm writes the .cmd shim without the executable bit.

$ ls -la ~/.npm-global/ | grep codex
-rwxr-xr-x  421  codex        <- the launcher bash can use
-rw-r--r--  341  codex.cmd    <- what shutil.which returns
-rwxr-xr-x  869  codex.ps1

Result: every npm-installed backend (codex, opencode, gemini) is rejected with a false backend CLI not found, and the real backend error stays hidden behind it.

The change

This is option B from the issue — the fallback lives in the shell layer that actually consumes the value, so resolve_binary and its Python-side callers keep their current contract. Happy to move it into resolve_binary instead if you prefer option A; the test does not care which layer fixes it.

When $BIN is unusable and looks like a resolved path, retry with the extensionless basename. A bare name that resolves to nothing fails exactly where it did before, so a genuine misconfiguration is still reported.

Test

New section in scripts/tests/run.sh, built on the existing fakes: a shimcodex + non-executable shimcodex.cmd pair, with PORCH_BIN_CODEX pointing at the backslash-spelled .CMD path.

The condition is reproducible on any platform — on Linux that path is simply an unresolvable filename — so the regression is covered by the existing ubuntu-latest / macos-latest job that runs run.sh, without needing the Windows job to install a backend CLI.

Verified in a Linux environment:

run	result
baseline (main)	957 passed, 0 failed
with this PR	960 passed, 0 failed
test kept, fix reverted	windows .cmd path falls back to extensionless launcher and windows .cmd path is not reported missing both FAIL with the reported error; missing bare binary still fails still passes

scripts/tests/platform_test.py also passes (20 tests, 4 skipped).

Note on the Windows CI gap

porch-smoke.yml does cover windows-latest, but no backend CLI is installed there, so a .cmd shim is never resolved and this class of bug is invisible to the matrix. The test added here closes that without changing the workflow. If you would rather also exercise it natively on Windows, that would need a shim fixture plus a Windows-enabled slice of run.sh — happy to do that in a follow-up if it is useful.

🤖 Generated with Claude Code

[rodion-m]

merged. thanks for contribution!