fix(toolkit-lib): reject discovered Windows paths containing %VAR%

[iankhou]

Follow-up to #1763 / #1849.

Summary

quoteShellPart() (toolkit-lib) — cmd.exe expands %VAR% even inside double quotes, and a cmd /c command line (how runUserCommandLine reaches the shell on Windows) cannot reliably escape a percent (doubling only works in batch files). A filesystem-discovered path carrying a %...% reference spliced into the user's app command line would therefore be silently rewritten — an environment variable expanded into the path. It is now refused loudly (ToolkitError('UnsafeWindowsPath', ...)) rather than executing something other than what is on disk.

Demonstration of the problem

Ran these commands on a Windows machine in cmd.

# USERNAME should be interpreted as a variable, as expansion occurs inside double quotes
D:\Users\ianhou>echo "C:\proj\%USERNAME%\app"
"C:\proj\ianhou\app"

# Here, we can't successfully escape USERNAME using %USERNAME%
D:\Users\ianhou>cmd /c echo "%USERNAME%"
"ianhou"

# And we can't do it using %%USERNAME%% either
D:\Users\ianhou>cmd /c echo "%%USERNAME%%"
"%ianhou%"

# Here is the only case where we escape it
D:\Users\ianhou>cmd /c echo "^%USERNAME^%"
"^%USERNAME^%"

Testing

• Unit test in environment.test.ts forcing platform=win32 and asserting a discovered %VAR% path is rejected.

This test demonstrates that given a %VAR% path on Windows, guessExecutable throws UnsafeWindowsPath instead of returning a quoted string. What it does NOT demonstrate is the problem itself - that cmd.exe actually expands %VAR% inside double quotes. However, we demonstrated that in the section "Demonstration of the problem" above.

Checklist

• Unit tests added/updated
• No manual edits to generated files

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.