Windows: Doctor binary resolver ignores %PATH%, reports installed git, gh, git-lfs, goose, cursor-agent as missing

### Before filing

- [x] I searched open and closed issues for duplicates.
- [x] I reproduced this on the latest release.
- [x] This is one bug, not several bundled together.

### Closest existing issue

#108 (Windows extended-length path prefix in the terminal panel). Same platform, different code path. Not a duplicate.

### What's broken

On Windows, the Berd Doctor binary resolver never consults `%PATH%` or `PATHEXT`. It reports git, GitHub CLI, git-lfs, Goose, and Cursor Agent as missing while all five are installed and resolvable on the system PATH.

### Steps to reproduce

1. Launch Berd on Windows 11.
2. Install Git for Windows and GitHub CLI so they land on the machine PATH. In my case `C:\Program Files\Git\cmd` and `C:\Program Files\GitHub CLI\`.
3. Confirm they resolve: `git --version` and `gh --version` both succeed in PowerShell and in Git Bash.
4. Run Berd Doctor.
5. Read the Tools and Agents sections.

No chat session or agent turn is involved.

### What you expected to happen

Berd Doctor finds any binary that Windows itself can resolve. Git, GitHub CLI, and git-lfs pass.

### What actually happened

Git and GitHub CLI report FAIL. Git LFS, Goose, and Cursor Agent report WARN as not installed. GitHub Auth reports FAIL because it depends on the failed `gh` lookup.

All of them are present:

| Reported | Actual |
| --- | --- |
| Git not found | git 2.55.0.windows.5, `C:\Program Files\Git\cmd` |
| GitHub CLI not found | gh 2.98.0, `C:\Program Files\GitHub CLI\` |
| Git LFS not installed | git-lfs 3.7.1 |
| Goose not installed | `C:\Users\\goose\goose.exe` |
| Cursor Agent not installed | `C:\Users\\AppData\Local\cursor-agent\cursor-agent.cmd` |
| GitHub Auth: gh not found | `gh auth status` shows a valid logged in account |

The resolver trace shows three strategies, and all three are Unix assumptions:

1. Login shell lookup spawns `/bin/zsh -l` and `/bin/bash -l`. Neither path exists on Windows, so both fail with os error 3.
2. Common install paths are Unix prefixes only, and they are joined with a mixed separator, for example `/usr/local/bin\git`. These can never match on Windows.
3. The npm strategy spawns bare `npm`, which is `npm.cmd` on Windows, so it fails with "program not found".

No strategy performs a plain `%PATH%` lookup with `PATHEXT` extension probing, which is where every one of these binaries actually lives.

Note that the Claude Code check passes. It resolves through Berd's own managed `packages\bin` directory rather than through `resolve_binary`, which is consistent with the resolver being the faulty component.

### How often does it happen?

Every time. Reliably reproducible.

### Berd version

0.6.2

### Operating system

Windows

### Model and provider

n/a

### Relevant log output

`berd.log` records nothing for the doctor run. The doctor's own resolver trace is the relevant output. Paths left intact because they are the subject of the bug.

```
# Check: Git - verify git is installed and reachable
not found via resolve_binary
resolve 'git':
strategy 1 - login shell path lookup:
/bin/zsh -l -c 'whence -p -- 'git'' => error: failed to spawn `/bin/zsh -l -c 'whence -p -- 'git''`: The system cannot find the path specified. (os error 3)
/bin/bash -l -c 'type -P -- 'git'' => error: failed to spawn `/bin/bash -l -c 'type -P -- 'git''`: The system cannot find the path specified. (os error 3)
strategy 2 - common install paths:
/opt/homebrew/bin\git => not found
/usr/local/bin\git => not found
/usr/bin\git => not found
/home/linuxbrew/.linuxbrew/bin\git => not found
strategy 3 - npm global install dirs:
C:\Users\\.npm-global/bin\git => not found
C:\Users\\.npm/bin\git => not found
npm prefix -g => error: failed to spawn `npm prefix -g`: program not found
not found in any location
```

The `gh`, `git-lfs`, `goose`, and `cursor-agent` traces are identical in shape.

### Suggested fix

Add a Windows strategy that resolves through `%PATH%` with `PATHEXT`, and skip the POSIX shell and Unix prefix strategies on Windows. Spawning npm should also use `npm.cmd` on Windows.

Start at the binary resolver's resolve_binary implementation and reproduce Berd Doctor on Windows using the resolver trace in the issue. The fix is done when PATH/PATHEXT resolution finds git, gh, git-lfs, Goose, and Cursor Agent, POSIX-only strategies are skipped on Windows, and npm is invoked through npm.cmd there.

Written by the indexing model from the issue text.