feat: Add Windows support for Copilot CLI

[ZacharyLuz]

Summary

Adds Windows support for Primer by properly handling the Copilot CLI on Windows.

Problem

On Windows, the Copilot CLI is installed as a .cmd\ wrapper file that cannot be directly spawned by Node.js \�xecFile(). The VS Code Copilot CLI shim (\copilot.bat) is also broken on Windows (see microsoft/vscode#291990).

Solution

• Use
  ode\ + \cliArgs\ approach to run
  pm-loader.js\ directly on Windows
• This bypasses the .cmd/.bat\ wrapper issues entirely
• Add Windows-specific paths for VS Code extension locations
• Maintain full backward compatibility with macOS/Linux

Changes

• \src/services/instructions.ts:
  • New \CopilotCliConfig\ type with \cliPath\ and optional \cliArgs\
  • \indCopilotCliConfig()\ returns config optimized for each platform
  • On Windows: uses
    ode\ with npm-loader.js path
  • On macOS/Linux: unchanged behavior

Testing

Tested on Windows 11 with:

• 
  px tsx src/index.ts instructions --repo .\ ✅
• 
  px tsx src/index.ts analyze\ ✅
• 
  px tsx src/index.ts tui\ ✅

[digitarald]

Hey @ZacharyLuz — thanks for putting this together and for the thorough testing on Windows 11! 🙏

The approach you proposed (using node + npm-loader.js to bypass .cmd/.bat wrapper issues) is exactly the pattern we ended up adopting in main. The vnext consolidation (PR #15) landed a unified src/services/copilot.ts module that includes:

• CopilotCliConfig with cliPath + cliArgs — matching the shape you proposed
• Windows npm-loader discovery (the node + npm-loader.js strategy)
• buildExecArgs() helper that handles the win32 .cmd shim workaround
• Platform-aware path resolution for VS Code extension locations

Since this is all in main now, I'm closing this PR. Your contribution and Windows testing really helped validate the right approach — thank you!