Consider wrapping $proc.WaitForExit in Stop-Slot in a try/catch for the process-exits-mid-wait race. #151

What

Wrap the $proc.WaitForExit($TimeoutSeconds * 1000) call in Stop-Slot (in windows/PoolSlot.ps1) in a try/catch.

Why

Get-SlotProcess opens $proc.Handle inside a try/catch and returns $null if the handle cannot be opened. However, once $proc is returned to Stop-Slot, the subsequent WaitForExit call is not guarded. If the process exits between the handle open and the wait — or if the handle becomes invalid mid-wait — WaitForExit can throw. This is a low-risk race in practice (the handle-open guard means we only reach this point for processes we can touch), but it is a defensive gap that can surface as an unhandled exception in Stop-Slot.

How

In Stop-Slot in windows/PoolSlot.ps1, wrap the $proc.WaitForExit($TimeoutSeconds * 1000) call in a try/catch. On catch, treat the process as exited (i.e., proceed down the same path as a successful wait that returned $true), since a process that exited mid-wait is by definition no longer running. Do not swallow unrelated exceptions silently — either narrow the catch to the expected exception types or log the caught exception at a debug/verbose level so the race is observable in diagnostics.

Files Affected

• windows/PoolSlot.ps1

Constraints

• Must not change the observable behavior of Stop-Slot for the normal (non-racing) case.
• Must not alter the existing Get-SlotProcess handle-open guard or its $null return contract.
• Must not change the Stop-Slot log messages (the "is not this slot any more" message is already flagged as a separate follow-up).
• Out of scope: the other suggested follow-ups from the same review (log-message changelog note, Register-SlotPidFile delete-between-Test-Path-and-Get-Item test, windows-pools.ps1 status behavior-change documentation).

LLM tier

Haiku — this is a mechanical, localized try/catch addition around a single call site with a clear, unambiguous expected behavior on catch.

Success looks like

• Stop-Slot no longer propagates an exception if the target process exits between the handle open in Get-SlotProcess and the WaitForExit call in Stop-Slot.
• Existing tests in process_tracking_test.ps1 and windows_pools_test.ps1 still pass unchanged.
• The normal path (process alive, wait times out or returns) behaves identically to before.

Failure looks like

• The try/catch swallows exceptions that indicate a real bug (e.g., a null $proc, an argument error) rather than only the exits-mid-wait race.
• The catch block changes control flow such that a still-running process is treated as exited and skipped.
• The change touches unrelated code in Stop-Slot or Get-SlotProcess.

Follow-up from AI review of PR #124.