Parallel runs on one machine share ~/.browserstack/BrowserStackLocal.exe.
While one run is executing it, Windows keeps the file locked for that
run's whole lifetime, so a second run that reaches the download path hits
EBUSY on the open. 1.5.15 no longer crashes on that, but it waits three
seconds and then tries to delete and re-download the file -- which cannot
succeed while the first run holds it, so the second run exhausts its
retries and never gets a tunnel (SDK-7713).

A locked binary that still answers --version is a working binary. Before
waiting on or replacing it, probe it and reuse it if it runs; probe again
after the wait, since an AV scan or a finishing writer can release it.
A file that does not run is still replaced as before. The version check
mirrors browserstack-local-python's __verify_binary.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

binaryPath() picks the file to look for with this.windows, but that flag
was only set inside getBinaryFilename(), which runs on the download path.
On a fresh LocalBinary it was still undefined, so on Windows binaryPath()
checked for "BrowserStackLocal" without the extension, never found it,
and re-downloaded the binary on every start -- writing over
BrowserStackLocal.exe each time.

That is what the SDK-7713 logs show: a second run started fourteen
seconds after the first run's tunnel was up, went straight to the
download, and hit EBUSY because the first run was executing the file.
It also means every Windows start paid for a full download.

Set the flag in the constructor, as Local.js already does. This replaces
the --version probe from the previous commit, which only reused the
binary after the collision; with the right filename there is no
download to collide.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

LOC-7472 Look for BrowserStackLocal.exe on Windows before downloading