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

[umair-a11y]

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.

[danielmiessler]

The probe fixes read right, and additive platform support is welcome. I don't have a Windows box to verify on, so this is an invited PR: send it with your own verification evidence and platform detection so the macOS path is untouched.

[emory]

I can try to pick this up. My employer workstation is at PAI 4.0.3, and the issue discouraging me is resolved now.

[danielmiessler]

All five confirmed against the source and all five fixed. They're real bugs, not a platform wishlist: the ':' split, the missing .exe/.cmd resolution, the absent Windows browser paths, the unconditional exec-bit check, and the POSIX shebang assumption.

Landed as inline process.platform === 'win32' branches beside the existing paths — no abstraction layer, matching the style the Linux Brave candidates already use. Doctor.ts isn't hook-wired, so the blast radius on macOS is nil, and we verified that directly: the full probe output is byte-identical before and after.

Two honest limits. The path.delimiter change can't be exercised here — delimiter resolves from the host, so it stays ':' on this machine, which is exactly why macOS is unchanged. And we can't dogfood Windows at all.

So this is landed but not closed: your own verification on native win32 and Git Bash is the missing evidence. If you can run bun LIFEOS/TOOLS/Doctor.ts there once the next release is out and paste what you get, that closes it.