Doctor.ts Windows probes: false negatives from POSIX-only which(), missing .exe/.cmd resolution, exec-bit and shebang checks

Splitting this out of #1730 (which tracked the setupUserSeparation symlink EPERM and is closed) — the Windows probe fixes described in my comments there never had a dedicated issue, so they cannot be tracked or closed on their own. Filing per that thread.

On a native Windows (win32, Git Bash) install, LIFEOS/TOOLS/Doctor.ts reports false negatives for most capabilities:

1. which() splits PATH on ':' instead of path.delimiter (';' on win32), so nothing on PATH resolves.
2. No .exe/.cmd/.bat probing — bare-name lookups miss Windows binaries; Bun.which() handles this if used.
3. Browser candidate paths are macOS/Linux only — no Windows Chrome/Brave install paths.
4. Unix exec-bit check fails on NTFS where the concept does not apply — needs a win32 skip.
5. Shebang check assumes /bin/bash resolution; on win32 the interpreter needs basename-on-PATH resolution.

All five are patched locally (verified working on Windows 11 + Git Bash, LifeOS v7.28.3) and I am happy to share the diff. As of v7.28.3 and current main, upstream Doctor.ts still carries the POSIX-only logic.

Environment: Windows 11 Home, Bun, LifeOS v7.28.3.

Start in LIFEOS/TOOLS/Doctor.ts and inspect the PATH, browser candidate, executable-bit, and shebang probe logic. Verify the changes on native Windows 11 with Git Bash; done means Windows executables and browser installations resolve correctly without POSIX-only failures, while POSIX behavior remains intact.

Written by the indexing model from the issue text.