What does this PR do?

On Windows, a normal hermes update can brick its own install by gutting the venv it is rebuilding.

hermes_cli/managed_uv.py:rebuild_venv() deletes the old venv in place and then recreates it:

if venv_dir.exists():
    shutil.rmtree(venv_dir, ignore_errors=True)      # (1)
result = subprocess.run([uv_bin, "venv", str(venv_dir), "--python", python_version])  # (2)

When any hermes.exe (gateway/desktop) is running — including the updater's own
interpreter — it holds venv\Scripts\python.exe open. Then (1) deletes
everything it can (site-packages, including certifi/cacert.pem) but
silently fails on the locked python.exe, leaving a half-gutted venv with no
pyvenv.cfg. (2) then aborts with "A directory already exists", so the venv is
never recreated. The result is a venv that still loads but whose every outbound
HTTPS call dies with FileNotFoundError (missing cacert.pem), and the CLI
reports No virtual environment found / ModuleNotFoundError: hermes_cli. No
automatic recovery — the venv must be rebuilt by hand. (This is issue #37881; we
hit it in production on Windows 11.)

This fixes the root cause: never destroy a venv that is in use. Move the old
venv aside atomically with os.replace, which fails fast and cleanly when the
venv is locked — leaving the working venv fully intact — instead of deleting it
piecemeal. Also pass --clear, and restore the moved-aside venv if the rebuild
itself fails.

Relationship to #37895 and #38051 (alternative approach). Both of those add
--clear to uv venv while keeping shutil.rmtree(ignore_errors=True). In the
real lock scenario --clear is insufficient: the running interpreter is the
venv's python.exe, so uv venv --clear cannot delete it either, and the
rmtree has already gutted site-packages. Moving the directory aside first
(os.replace) is what actually prevents the brick — it bails out before any
deletion when the venv is in use, and tells the user to stop the gateway. This
PR includes that fix; happy to fold it into whichever PR the maintainers prefer.

Related Issue

Fixes #37881

Type of Change

• ðŸ�› Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/managed_uv.py — rebuild_venv(): move the existing venv aside with
  os.replace (abort without deletion if it's in use), pass --clear to
  uv venv, and restore the old venv if the rebuild fails. Updated docstring.
• tests/hermes_cli/test_managed_uv.py — regression tests (below).

How to Test

1. On Windows, with a Hermes gateway/desktop running (so venv\Scripts\python.exe
   is locked), run hermes update. On main this bricks the venv
   (pyvenv.cfg gone, later HTTPS calls raise FileNotFoundError).
2. With this patch, rebuild_venv aborts cleanly with "venv is in use; stop the
   gateway/desktop and retry" and the existing venv is left fully intact.
3. Unit: pytest tests/hermes_cli/test_managed_uv.py -k RebuildVenv — see new
   tests proving an in-use venv is never deleted and a failed rebuild is restored.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(uv): ...)
• I searched for existing PRs — found fix(cli): pass --clear to uv venv in rebuild_venv to avoid Windows brick #37895 and fix(config): add --clear flag to uv venv rebuild to prevent Windows bricking #37881 #38051; this is intentionally a more complete alternative (see note above), not a blind duplicate
• My PR contains only changes related to this fix
• I've run pytest tests/ -q and all tests pass — ran TestRebuildVenv (all pass on Windows/Py3.12); did not run the full suite. Note: 6 pre-existing tests in test_managed_uv.py (TestResolveUv/TestEnsureUv/TestUpdateManagedUv/TestInstallUvInternals) fail on Windows independent of this change (POSIX chmod/os.access(X_OK) assumptions)
• I've added tests for my changes
• I've tested on my platform: Windows 11 (Python 3.12)

Documentation & Housekeeping

• I've updated relevant documentation (docstring on rebuild_venv)
• cli-config.yaml.example — N/A
• CONTRIBUTING.md / AGENTS.md — N/A
• I've considered cross-platform impact — os.replace is correct on POSIX too; behavior there is unchanged (move-aside then recreate)
• tool descriptions/schemas — N/A

Logs

Production failure signature that this prevents:

WARNING hermes_cli.managed_uv: venv rebuild failed: A directory already exists at: ...\venv
ERROR  agent.conversation_loop: API call failed after 3 retries. [Errno 2] No such file or directory
       | provider=custom base_url=http://127.0.0.1:8001/v1 model=qwen3.6-27b-gptq