fix: bypass Selenium Manager only where it cannot run

PR #170 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 also regressed browser resolution
in 0.10.2 for everyone else.

selenium-webdriver's Firefox Driver.createSession() calls getBinaryPaths() only
when the supplied DriverService has no executable, and that one call resolves
geckodriver *and* the Firefox binary it injects into moz:firefoxOptions.binary.
Handing the service a path therefore also opts out of finding Firefox. On a
machine with no system Firefox, 0.10.1 launched fine because Selenium Manager
downloaded and selected one under ~/.cache/selenium/firefox/; 0.10.2 fails with
"Unable to detect Firefox binary automatically" unless --firefox-path is given.

This is the same mechanism the Android branch relies on deliberately, where
skipping getBinaryPaths() is what stops a desktop binary being injected over
androidPackage.

Resolve geckodriver ourselves only where Selenium Manager genuinely cannot do
the job: win32, where ServiceBuilder() invoked from the MCP hangs (Bug 2040849),
and non-x64 Linux (Bug 2062055). Elsewhere leave the executable unset so
Selenium Manager resolves both halves as it did in 0.10.1.

The test added in #170 asserted an explicit path on every platform, so it
encoded the regression as expected behaviour and could not have caught this. It
is replaced with per-platform cases covering both sides, verified to fail
against the 0.10.2 code and pass against this change.

Reported and diagnosed by @mightykatun on #170.