fix: fail when launcher mutex wait times out

[bobthecomputer]

Summary

• require the Windows launcher to own its named mutex before entering installer or process lifecycle work
• fail with a clear nonzero result when the bounded mutex wait expires
• preserve abandoned-mutex recovery, where the waiting thread becomes the owner
• keep all three distributed PowerShell launchers byte-identical
• add a deterministic regression for the timeout path to the Windows install workflow

Root cause

Mutex.WaitOne(timeout) returns false on a normal timeout. The launcher cast that result to void, so a second invocation continued without owning the mutex after 190 seconds. This defeated the single-instance guard precisely when the first launcher was still slow or stuck.

Validation

• new regression fails against current main because the old launcher reaches work after the mutex timeout
• powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\tests\start-monk-agent-mutex-timeout.ps1
• PowerShell parser checks for all changed scripts
• all three launcher copies have identical SHA-256 hashes
• powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\tests\block-monk-windows.ps1
• git diff --check

Fixes #146