fix: bypass Selenium Manager only where it cannot run

[shoemoney]

Fixes the browser-resolution regression in 0.10.2 reported by @mightykatun on #170. Their diagnosis was correct and this is essentially the fix they proposed.

What broke

#170 (mine) made every platform pass an explicit geckodriver path to firefox.ServiceBuilder. That fixed aarch64 Linux, where Selenium Manager ships an x86-64 binary that cannot execute, but it regressed everyone else.

selenium-webdriver's Firefox Driver.createSession() calls getBinaryPaths(caps) only when the supplied DriverService has no executable. That one call resolves geckodriver and the Firefox binary, which it then injects into moz:firefoxOptions.binary. Handing the service a path therefore also opts out of finding Firefox.

On a machine with no system Firefox and none on PATH:

• 0.10.1: Selenium Manager downloads and selects a Firefox under ~/.cache/selenium/firefox/, and list_pages succeeds with no --firefox-path.
• 0.10.2: first tool call fails with Unable to detect Firefox binary automatically, please provide the full path via --firefox-path.

This is the same mechanism the Android branch in connect() relies on deliberately, where skipping getBinaryPaths() is what stops a desktop binary being injected over androidPackage. The comment there describes the behaviour exactly. I changed the desktop path without noticing it applied there too.

The fix

Bypass Selenium Manager only where it genuinely cannot do the job:

• win32, where ServiceBuilder() invoked from the MCP hangs (Bug 2040849)
• non-x64 Linux, where the Selenium Manager binary cannot execute (Bug 2062055)

Everywhere else the executable is left unset, so Selenium Manager resolves both halves as it did in 0.10.1.

On the test

The unit test I added in #170 asserted an explicit service executable on every platform. It encoded the regression as the expected behaviour, so it could never have caught this, and it passed happily while users broke. It is replaced with per-platform cases covering both sides.

I verified these actually fail against the shipped code rather than just passing against mine: reverting core.ts to the 0.10.2 logic fails the two "leaves the service executable unset" cases and passes the rest.

× leaves the service executable unset on linux/x64, so Selenium Manager still finds Firefox
× leaves the service executable unset on darwin/arm64, so Selenium Manager still finds Firefox
  Tests  2 failed | 26 passed (28)

With this change: 686 unit tests pass, lint, prettier and both typecheck configs clean.

Not covered here

The longer-term options @mightykatun raised, an architecture-compatible Selenium Manager binary or our own browser resolver, would let all platforms share one path. This is the minimal restoration of 0.10.1 behaviour for affected users; happy to follow up on either.

Sorry for the breakage, and thanks to @mightykatun for a report that arrived with the root cause already in it.

[juliandescottes]

Thanks! I will just trim the comment and merge.