fix(windows): launch canonicalized batch shims through cmd.exe

[TreyThomasCodes]

Problem

On Windows, LSP executables discovered through canonicalized lsp_paths_extra directories can be represented as extended-length (\\?\\...) paths. Passing a .cmd or .bat shim in that namespace to cmd.exe breaks npm shim %~dp0 handling and the server fails to start with The system cannot find the path specified.

Native .exe launches are unaffected. The path should remain canonical for internal identity and filesystem operations.

Proposed design

At the shared batch-launch boundary only, translate recognized canonical paths into the spelling cmd.exe supports:

• \\?\\C:\\... -> C:\\...
• \\?\\UNC\\server\\share\\... -> \\server\\share\\...
• preserve unsupported verbatim namespaces unchanged.

This applies equally to npm LSP shims and formatter/tool shims, while leaving native executable launching unchanged.

Evidence

The installed yaml-language-server@1.24.0 fails through the AFT configure + LSP-inspect path before conversion and starts successfully once the batch launch argument is converted at this boundary.

Implementation

PR #293 implements the change with DOS, UNC, percent-character, space, and unsupported-namespace regression coverage.

[aft-alfonso]

Design approved and labelled: translating \\?\\C:\\... and \\?\\UNC\\... only at the shared batch-launch boundary (cmd.exe cannot resolve verbatim paths for %~dp0), leaving the canonical form for identity and filesystem work and unsupported namespaces untouched, is the shape we want - it changes a comparison-local spelling, not a returned path form. PR #293 carries the change with the DOS/UNC/percent/space/unsupported-namespace coverage; the gate is green on it now and it merges once its CI matrix finishes. Thanks for filing the issue the gate asked for.