[Bugs] On Windows, agent-merge skill scripts run under WSL bash and fail (bundled gh/jq not on WSL PATH)

### Short summary

On Windows, the agent-merge skill runs its helper script with bare `bash` (e.g. `bash check-merge-conditions.sh `). On a standard Windows dev box that has WSL installed, `bash` resolves to `C:\Windows\System32\bash.exe` (the WSL launcher), so the script executes **inside the WSL distro**, where the Copilot-bundled `gh` and the user's `jq` are not on PATH. The script fails immediately with `No such file or directory` / exit 127, so agent-merge cannot evaluate merge conditions.

### Affected version or release

- GitHub Copilot app: 0.2.27
- Copilot CLI: 1.0.60
- OS: Windows 11 Enterprise (10.0.26200)
- WSL: installed (default distro Ubuntu-22.04)
- Git for Windows: 2.53.0.windows.3 (Git Bash present at `C:\Program Files\Git\bin\bash.exe` but NOT on PATH, which is the Git for Windows default)

### What happened?

When agent-merge follows the skill instructions and runs `bash check-merge-conditions.sh ...`:

```
/bin/bash: C:Users...app-skills\agent-merge\check-merge-conditions.sh: No such file or directory
# exit 127
```

The script never runs because:
1. `bash` resolves to the WSL launcher (`System32\bash.exe`), not Git Bash.
2. Inside WSL, the Copilot-bundled `gh` (`%LOCALAPPDATA%\copilot-desktop-gh-*\gh`) and the user's `jq` (mise shim) are not available, so even when the path is corrected the script's `gh`/`jq` calls fail.

Confirmed root cause on this machine: the only `bash.exe` entries on PATH are the two WSL launchers (`System32`, `WindowsApps`); `C:\Program Files\Git\bin` is intentionally not on PATH (Git for Windows default). So bare `bash` -> WSL is the out-of-the-box outcome.

### Why this is not environment-specific

This reproduces for the common configuration class "Git for Windows (default install) + WSL installed", not a one-off misconfiguration:
- Git for Windows deliberately keeps `bash` off PATH to avoid shadowing system tools.
- WSL places `bash.exe` in `System32`.
- Therefore bare `bash` -> WSL is the default behavior for a large population of Windows dev machines, and the skill always invokes bare `bash`.

It happens on every agent-merge run/session on such a machine.

### Workaround

Invoking the script through Git Bash explicitly works, because Git Bash inherits the Windows PATH and can see the bundled `gh` and the `jq` shim:

```
& "C:\Program Files\Git\bin\bash.exe" -lc "/c/Users/.../agent-merge/check-merge-conditions.sh "
```

(With Git Bash the WSL/PATH problem is gone; a separate `Failed to fetch requested reviewers` / exit 2 can still occur from the script's reviewer fetch, but that is a different layer.)

### Suggested fixes

1. When running skill `.sh` scripts on Windows, prefer Git Bash (`C:\Program Files\Git\bin\bash.exe`) over a bare `bash` that resolves to WSL.
2. Or ensure the interpreter used for skill scripts can see the Copilot-bundled `gh` and `jq`.
3. Or provide a PowerShell-native execution path / fallback for these skills on Windows.

### Related

- github/copilot-cli#508 (Support Git Bash)
- github/copilot-cli#2981 (Copilot CLI uses Unix-only commands on Windows)

Start by locating the agent-merge skill instructions and the check-merge-conditions.sh invocation, then reproduce the bare bash command on the described Windows setup. Compare its behavior with the explicit Git Bash workaround and inspect how the script finds gh and jq. Done means agent-merge can run its helper scripts on the affected configuration without the WSL path failure.

Vom Indexierungsmodell aus dem Issue-Text verfasst.