fix(admin): spawn chrome.exe directly on Windows for chrome:// inspect URL (#290)

[voidborne-d]

Closes #290.

Bug

webbrowser.open(\"chrome://inspect/...\") on Windows routes through ShellExecute, which has no registered handler for the chrome:// scheme. Instead of opening Chrome to the inspect page, Windows pops a "Get an app to open this" Microsoft Store dialog — the setup flow then sits in its retry loop waiting for the user to click Allow on a tab that never opened.

_open_chrome_inspect() already detects macOS and bypasses webbrowser.open via AppleScript for the same reason. Windows had no equivalent branch and fell through to the broken webbrowser.open(url, new=2) call.

Fix

Match the macOS branch's intent — talk to Chrome directly. Walk the standard Chrome install locations on Windows (%PROGRAMFILES%, %PROGRAMFILES(X86)%, %LOCALAPPDATA%) and spawn chrome.exe with the URL as a command-line argument. If no Chrome binary is found, fall through to the pre-existing webbrowser.open path so behaviour on Linux (and headless Windows installs) is unchanged.

Why this shape

• Mirrors the existing macOS pattern: detect platform → use a platform-native channel → fall back if it errors. No reshape of the function's contract.
• Same env vars / install paths the rest of the Chrome-on-Windows ecosystem relies on (chrome://settings/help, Selenium, Playwright, etc.).
• Doesn't touch Edge / Brave / Chromium. The URL is hard-coded chrome://...; if chrome.exe isn't installed the user wouldn't be at the inspect page anyway. Keeping the diff narrow.

Tests

tests/unit/test_admin.py:

• test_open_chrome_inspect_invokes_chrome_exe_directly_on_windows — under a Windows mock with a fake chrome.exe on %PROGRAMFILES%, asserts subprocess.Popen is called with [chrome.exe, \"chrome://inspect/#remote-debugging\"] and webbrowser.open is not called.
• test_open_chrome_inspect_falls_back_to_webbrowser_when_no_chrome_exe_on_windows — under a Windows mock with no env vars set, asserts the pre-existing webbrowser.open fallback still runs (so users on unusual Chrome installs get the same behaviour they had before).

Reverting just the admin.py change with the new tests in place fails the first test (red), confirming the test catches the bug. Full suite: 42 passed.

Test plan

• pytest tests/unit/ — 42/42 pass
• On a real Windows 11 machine: run browser-harness --setup with a fresh Chrome profile and remote-debugging disabled — should open chrome://inspect/#remote-debugging directly in Chrome instead of the Microsoft Store dialog (I can't test this myself; would appreciate a Windows reviewer).

AI disclosure

Implementation drafted with Claude Code assistance. Bug was filed by @Wievondii in #290 with a proposed fix; this PR applies that proposal with platform-native env-var lookup, a graceful fallback, and unit-test coverage.

---

Summary by cubic

Fixes opening chrome://inspect on Windows by launching Chrome directly instead of using webbrowser. This avoids the Microsoft Store dialog and unblocks the setup flow. Closes #290.

• Bug Fixes
  • On Windows, search standard install paths and spawn chrome.exe with the URL; fall back to webbrowser.open if Chrome isn’t found.
  • macOS behavior unchanged (AppleScript). Linux/headless behavior unchanged.
  • Added unit tests for both the chrome.exe path and the fallback.

^{Written for commit b063452. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files