fix(cli): pass --clear to uv venv in rebuild_venv to avoid Windows brick

[teknium1]

hermes update no longer bricks the install on Windows when it rebuilds the venv.

When the running interpreter lives inside the venv being rebuilt, Windows locks python.exe, so shutil.rmtree(..., ignore_errors=True) silently leaves a half-deleted directory (pyvenv.cfg gone, Scripts/python.exe still present). The subsequent uv venv then aborts with A directory already exists, leaving a broken venv → ModuleNotFoundError: hermes_cli.

Changes

• hermes_cli/managed_uv.py: pass --clear to uv venv in rebuild_venv() so uv replaces any leftover directory rmtree couldn't fully remove.
• tests/hermes_cli/test_managed_uv.py: 2 regression tests (--clear is passed; rebuild succeeds when rmtree leaves residue).

Validation

	Before	After
uv venv over leftover residue	error: A directory already exists (brick)	succeeds, valid pyvenv.cfg

Verified live with a real uv binary: no---clear returns exit 2 with the exact "A directory already exists" error; --clear returns 0 and produces a working venv. 17/17 test_managed_uv.py pass.

Fixes #37881.

Salvaged from #37895 by @jackjin1997 (clean implementation against current managed_uv.py); also supersedes @kyssta-exe's #37965 / #38051, which fixed the same bug from a stale fork base. Credit to both contributors.

Infographic

[github-actions]

🔎 Lint report: hermes/hermes-de8f5c66 vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 9802 on HEAD, 9802 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5086 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[teknium1]

Closing as already fixed on main.

The Windows venv brick (#37881) was fixed in c136eb4 ("fix(update): harden venv rebuild + verify core deps after install"), which uses the same --clear mechanism you identified — implemented as a conditional retry (only retries with --clear when uv's stderr reports "already exists", so it doesn't mask real failures like disk-full or interpreter-download errors), plus a post-install dependency-verification pass as belt-and-suspenders.

Thanks for the clean fix and the precise root-cause writeup — you correctly diagnosed the locked-python.exe / rmtree interaction. Credit to you for independently landing on the right mechanism.