fix(dynamic-workflow): resolve newest cli.js directly on Windows, avoid the PowerShell -File hop

[modacker]

What changes

Fixes Windows mcode launcher resolution in mcode-location.mjs — two failure modes observed on a real Windows deployment (details anonymized; a user's debugging session was shared with us verbatim):

1. PowerShell 5.1 breaks the -File hop. A resolved mcode.cmd with a sibling mcode.ps1 is invoked as powershell -NoProfile -File mcode.ps1 exec --input - --cwd .... Under -File, PowerShell binds flag-shaped tokens (-input, --cwd, --timeout …) as its own named parameters, so the exec argv never reaches the CLI — parameter-binding errors on every invocation. (The user's attempted --% stop-parsing cannot help: it affects interactive command lines, not -File argument passing.)
2. The no-ps1 fallback accepts a stale sibling install. With the .ps1 renamed away (the user's workaround), resolution falls back to dirname(mcode.cmd)/node_modules/@minimax-ai/code/cli.js — the npm-global layout, whichever version sits there. On a machine with an old install (0.2.x, missing current exec flags) providing the PATH shim while a newer official install exists, resolution silently picked the 0.2.x entry and every exec call died on an unknown flag. The user eventually junction-linked the new cli.js into the expected path — a workaround this PR makes unnecessary.

The fix

• On win32, prefer a directly spawnable node entry over the .ps1 hop: collect candidate cli.js locations (shim sibling node_modules, official lib/node_modules, official root node_modules) and pick the newest by package version — mixed installs resolve to the freshest CLI regardless of which install owns the PATH shim.
• The powershell -File hop remains only as a documented last resort when no node entry exists in any layout.
• POSIX resolution is untouched (guarded by a regression test).

Test evidence

• New checks/win-launcher.check.mjs (7 tests): the mixed-install matrix is reproduced from POSIX by faking the win32 on-disk layout and passing platform:'win32' + controlled PATH/PATHEXT (resolution is pure filesystem probing): ps1-present-with-old-sibling + newer official → direct node entry of the newest; ps1 renamed + stale sibling → newest official, never the stale one; newest-wins regardless of origin; single npm layout; ps1 last resort preserved (with -NoProfile,-File,<launcher> argv pinned); no-entry error message preserved; POSIX unchanged.
• TDD order: the matrix was written against the expected behavior first and verified red (4/7) on current main before the fix → 7/7 after.
• Full plugin suite 89/89, packaged MCP smoke 1/1, byte-reproducible rebuild. Real-Windows behavior is exercised by this repository's windows CI job on the PR.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[modacker]

Substantially expanded after receiving the reporter's full field debugging notes (Windows 11 / PowerShell 5.1 + pwsh 7.6.6 / Node 26 / mcode 0.4.12; identities sanitized). Their four findings, mapped to this PR:

1. Empty-extension priority conflict — executablePath probed the '' PATHEXT entry first, resolving mcode to the extensionless POSIX shell shim shipped beside mcode.cmd in the install root; spawn then fails with ENOENT. → Bare names now match PATHEXT variants only; commands that already carry an extension (pwsh.exe) still probe directly.
2. PS 5.1 launcher hop broken (their A/B testing: PS7 pwsh -File works; PS 5.1 fails two ways — flag-shaped argv bound as cmdlet named parameters, and piped stdin not forwarded through the nested invocation), plus the plugin's PS priority was inverted (powershell.exe before pwsh.exe). → The main path no longer hops through PowerShell at all (direct node entry); the last-resort hop now prefers pwsh.exe.
3. Stale fallback cli.js — the real current CLI lives in the staged-installer layout releases/<version>/node_modules/@minimax-ai/code/cli.js (what .mcode-launcher.cmd targets), while the flat node_modules beside the shim held a 0.2.x entry lacking current exec flags (unknown option '--prompt-mode'). → releases/*/node_modules/... now competes in the version-pick pool; proximity no longer beats version.
4. The cleanest existing path was never used — equivalent outcome now achieved without any intermediate: direct node + the newest cli.js.

New regressions reproduce the reporter's exact on-disk layout from POSIX (extensionless shim + mcode.cmd + ps1 + stale flat node_modules + releases/0.4.12): red 3/3 on the previous head, green after. Suite now 10/10 launcher tests, 92/92 plugin-wide, packaged smoke 1/1, byte-reproducible rebuild.

The reporter also supplied maintainer-runnable repro commands for the PS 5.1/PS7 pair and the direct mcode.cmd path, plus failing run IDs — kept out of this comment for privacy, available on request via the reporter.

[hetaoBackend]

Request changes for exact current head 67980640498827fd2f7feec688127eb79e2ca4f4.

Two Windows-launcher correctness/evidence blockers remain:

1. The resolver does not follow the authoritative active release. src/mcode-location.mjs:53-70 enumerates every releases/* directory and chooses the numerically largest parsed package version. It never resolves a launcher/current pointer, and the parseInt comparison does not implement SemVer or define stable-versus-prerelease/tie behavior. A retained beta/newer directory or rollback can therefore select a different CLI from the release the installed launcher would run. checks/win-launcher.check.mjs:103-112 currently locks in highest-numeric-directory behavior rather than testing the active release contract. Resolve the authoritative active target, or document and implement a complete version/channel/tie policy with rollback tests.

2. The Windows-specific test is not run on Windows. checks/win-launcher.check.mjs:5-9 says real Windows behavior is covered by repository CI, but .github/workflows/dynamic-workflow.yml:37-48 runs only checks/process-tree.check.mjs in the Windows job. The launcher suite currently runs under POSIX while merely injecting platform: win32, so it does not exercise Windows path, PATHEXT, filesystem, or spawn semantics. Run win-launcher.check.mjs in the Windows job and preferably add an end-to-end fake cli.js spawn with spaces and flag-shaped argv.

I confirmed the good parts: .cmd and PATHEXT probing, npm-prefix layout, separated argv with shell:false, PowerShell fallback only when no Node entry is found, source/dist sync, and the existing exact-head CI are sound. [code]smith is skipped and was not used as evidence.