fix(update): make conductor update reliable on Windows (running-process check, retry, better errors)

[jrob5756]

Summary

conductor update fails frequently on Windows. Root cause: when another conductor process is running (foreground conductor run --web, background dashboards from --web-bg, IDE-spawned workers), it holds file locks on the entrypoint executable and on files inside %LOCALAPPDATA%\uv\tools\conductor-cli\. uv tool install --force then errors with "Access is denied" or "file is in use", and the previous error reporting only printed proc.stderr with no remediation.

Changes

1. Pre-flight running-process check

Detects other Conductor processes via tasklist on Windows and ps elsewhere. If any are found, prints them with PIDs and aborts with guidance:

Warning: 2 other Conductor processes are running:
  • PID 12345: /usr/local/bin/conductor run plan.yaml --web
  • PID 67890: conductor-cli (uv tool venv child)

Running processes can hold file locks that cause the upgrade to fail
(especially on Windows).
Stop them first (e.g. `conductor stop --all` for background dashboards),
then re-run `conductor update`.
To upgrade anyway, re-run with `conductor update --force`.

_looks_like_conductor_process() matches the conductor entrypoint, python -m conductor, and uv tool run conductor without false positives on unrelated paths.

2. Retry loop (mirrors install.ps1)

run_update now retries the uv tool install invocation up to 3 times with a 2-second delay, matching the existing logic in install.ps1 for transient Windows Defender / file-lock failures. Mid-sequence success short-circuits.

3. Better error reporting

• Surfaces both proc.stdout AND proc.stderr (previously only stderr)
• On Windows, detects "access is denied" / "in use" / "locked" patterns and points users at stopping conductor processes
• Always shows the Defender exclusion command (Add-MpPreference -ExclusionPath ...) on Windows failure

4. Broader Windows .exe rename

_rename_windows_exes() now also moves these out of the way before uv tool install:

• %LOCALAPPDATA%\uv\tools\conductor-cli\Scripts\conductor.exe — the most common cause of failed self-upgrades
• %APPDATA%\uv\tools\conductor-cli\Scripts\conductor.exe — alt path on some uv versions

(In addition to the previously-covered ~/.local/bin/conductor.exe and the exe found on PATH.)

5. New --force flag

conductor update --force skips the pre-flight check for users who are confident the install will succeed.

Tests

• +5 new tests in TestRunUpdate:
  • test_aborts_when_other_conductor_running — pre-flight detects processes and aborts without invoking install
  • test_force_skips_pre_flight — --force proceeds even with running processes
  • test_retry_succeeds_on_second_attempt — transient failure → success short-circuits
  • test_failure_surfaces_stdout_and_stderr — both streams shown
  • Pre-flight & sleep autouse fixture so existing tests are unaffected
• Updated test_upgrade_failure to assert call_count == 3 (retries to exhaustion)
• All 62 update tests pass; full tests/test_cli (301 tests) passes
• make lint ✓
• uv run ty check ✓

Verification path on Windows

After this lands, a Windows user hitting "update fails almost every time" should:

1. Run conductor update — gets immediate, actionable feedback if processes are running
2. Run conductor stop --all to clean up background dashboards
3. Close any foreground conductor run terminals
4. Re-run conductor update — now succeeds, or shows a clear error with Defender remediation if Defender is the issue