fix(windows): use OpenProcess for liveness check in pid.py (#166)

[jrob5756]

Summary

Fixes #166. conductor stop (and --all / --port) crashes on Windows whenever a PID file exists in ~/.conductor/runs/:

OSError: [WinError 11] An attempt was made to load a program with an incorrect format

The crash happens before any process is stopped, making the command effectively unusable on Windows.

Root cause

_is_process_alive used the Unix idiom os.kill(pid, 0) to probe existence without sending a signal. On Windows that idiom is not a no-op — per the CPython docs, any signal value other than CTRL_C_EVENT / CTRL_BREAK_EVENT routes through TerminateProcess. Depending on the target process's bitness/image type, this can raise OSError subclasses that neither ProcessLookupError nor PermissionError cover (e.g. WinError 11 / ERROR_BAD_FORMAT). The exception escaped out of read_pid_files() and crashed the CLI.

It would also be unsafe even if it didn't raise: a "successful" os.kill(pid, 0) on Windows would actually terminate the target process with exit code 0.

Fix (src/conductor/cli/pid.py)

Split _is_process_alive into a platform dispatcher and two implementations:

• _is_process_alive_posix keeps os.kill(pid, 0) and adds a defensive OSError catch that logs at debug and returns True. Treating an unexpected error as "assume alive" prevents a transient OS hiccup from silently dropping a still-running workflow's PID file or crashing conductor stop.
• _is_process_alive_windows uses ctypes to call OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, ...) followed by GetExitCodeProcess. Maps ERROR_INVALID_PARAMETER → not alive, ERROR_ACCESS_DENIED → alive, and any other failure → assume alive (with a debug log).

No new dependencies added — ctypes is part of the Python stdlib. Windows-only ctypes attributes are flagged for ty with # type: ignore[unresolved-attribute], matching the codebase's existing convention for platform-conditional code.

Tests (tests/test_cli/test_pid.py)

• TestIsProcessAlivePosix — alive, ProcessLookupError, PermissionError, and the regression case (generic OSError, exactly the scenario the issue suggested would have caught this earlier).
• TestIsProcessAliveDispatch — verifies the dispatcher routes to the right implementation based on sys.platform.
• TestIsProcessAliveWindows — Windows-only smoke tests using real kernel32.dll for the current process and an invalid PID, gated with pytest.mark.skipif(sys.platform != "win32").
• TestReadPidFilesDoesNotCrashOnOsError — full integration through read_pid_files() simulating the Windows-style failure on the POSIX path; asserts no exception escapes and the PID file is preserved (rather than silently deleted).

Verification

• uv run pytest tests/test_cli/test_pid.py → 20 passed, 2 skipped (Windows-only).
• uv run pytest tests/test_cli/ → 353 passed, 2 skipped.
• uv run ruff check / ruff format --check — clean.
• uv run ty check src/conductor/ — back to baseline (no new diagnostics).

Notes

• Behavior on macOS / Linux is unchanged for the normal alive / dead / no-permission cases.
• The Windows code path lives behind sys.platform == "win32" and uses lazy ctypes imports, so it has zero impact on POSIX startup or runtime.
• The STILL_ACTIVE (259) sentinel has the well-known corner case that a process can legitimately exit with code 259 and be reported as alive; for our use case (cleaning up stale workflow PID files) this is an acceptable known limitation.

Closes #166