fix(dev-mcp): resolve ripgrep on Windows PATH

[sumit-m]

Problem

rg.rs splits and rejoins PATH on ':'. Windows separates entries with ;, and every entry carries a drive colon, so C:\tools\bin;C:\Users\x\bin shredded into C, \tools\bin;C, \Users\x\bin — no usable directory survived. The lookup also joined the bare name rg, omitting the .exe suffix, so is_file() would have failed even on an entry that did survive.

Net effect on Windows: try_system_rg can never succeed, and every search silently falls through to the built-in walker. Degraded rather than broken, which is presumably why it went unnoticed.

Change

• clean_path and which_rg use env::split_paths / env::join_paths, which use the platform separator.
• New RG_EXE const supplies rg.exe on Windows, rg elsewhere.
• clean_path now works in OsString rather than String, avoiding a lossy round-trip.
• A join_paths failure yields an empty PATH rather than the original. That is the safe direction: returning the original would put this shim's own directory back in play and risk recursing into ourselves.

Tests

Four new tests: which_rg finds a binary past an earlier PATH entry (the regression guard — both entries are absolute, so on Windows they carry drive colons), returns None when no entry holds the binary, ignores empty entries, and clean_path's filter drops the directory holding the shim.

cargo clippy -p buzz-dev-mcp --all-targets clean. Note shell::tests is flaky on Windows under the parallel suite both before and after this change — Shim::install calls env::remove_var and rebuilds PATH from process env, which parallel test threads race. Untouched here.