Add a non-blocking Windows CI lane for the shipped gl / git-remote-gitlawb binaries

[beardthelion]

Problem

We ship Windows binaries with zero Windows test coverage.

release.yml builds x86_64-pc-windows-msvc on windows-latest and ships gl and git-remote-gitlawb to Windows users (release.yml:129,163). But:

• No Windows CI. pr-checks.yml is ubuntu-latest only. The single windows-latest in the repo is the release build step, which runs cargo build --release (release.yml:172) and never cargo test.
• Windows is deliberately best-effort: continue-on-error: true for Windows targets, "a Windows-only failure must not block the release" (release.yml:108-158).

So every change to the shipped Windows CLIs (e.g. the multi-round fetch fix in #192) reaches Windows users without a single test run on Windows. Test authors have been gating platform-sensitive tests #[cfg(unix)] (process-group teardown in git-remote-gitlawb/tests/real_git_fetch.rs) partly because there's no Windows lane to run or debug them on — which institutionalizes the blind spot.

Proposal

Add a non-blocking Windows CI lane to pr-checks.yml that runs the shipped crates' test suites on windows-latest:

• cargo test -p gl -p git-remote-gitlawb (the two crates shipped on Windows).
• continue-on-error: true (or a non-required check), matching the existing "Windows best-effort" release posture: a Windows-only failure is visible on the PR but does not block merge.
• Ensure git is available on the runner (it is, on windows-latest).

This makes Windows regressions visible without making Windows a hard gate, and it makes the #[cfg(windows)] regressions added in #192 (the run_bounded Job Object teardown) load-bearing instead of never-run.

Follow-on

Once the lane exists, un-gate the currently #[cfg(unix)] harness/integration tests in git-remote-gitlawb (or add Windows companions) so they actually exercise the shipped Windows path. #192 lands the Job Object teardown that those tests depend on.