fix(amazonq): make cmd.exe builtin detection locale-independent

[peschuster]

Problem

On non-English Windows systems, executeBash command validation is broken:
every unknown command passes validation as a supposed cmd.exe builtin.

resolveWindowsCommand probes cmd.exe /c help <cmd> and checks the output
for the English marker "This command is not supported by the help utility".
That string is localized, so e.g. on a German-locale system the marker never
matches and any command that where cannot find is accepted as a builtin.

This is visible in the existing test suite: "whichCommand cannot find the first arg" (executeBash.test.ts) fails on a de-DE Windows machine against
current main with Missing expected rejection, because noSuchCmd
incorrectly passes validation.

Solution

Replace the locale-dependent help probe with a static set of cmd.exe
internal commands, checked before falling back to where for external
commands. As a side effect this saves one child-process spawn when
validating non-builtin commands.

Added a win32-gated test asserting that a builtin without an executable on
PATH (assoc) passes validation.

Testing: ran the full executeBash.test.ts suite on German-locale
Windows 11: 57 passing with this change; without it, the existing
noSuchCmd test fails as described above.

License

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