fix(update): harden venv rebuild + verify core deps after install

Two complementary fixes for a silent partial-install failure that bit
``hermes update`` in the wild: a fresh checkout pulled 145 commits,
``rebuild_venv`` failed to recreate the venv on Windows because
``shutil.rmtree(ignore_errors=True)`` couldn't delete files held open by
the running ``hermes.exe`` shim. ``uv venv`` then refused with
"A directory already exists at: venv" and the update fell back to
installing on top of the stale venv. The resulting partial install
missed exactly one newly-added base dep — ``pathspec==1.1.1`` — which
``hermes desktop --build-only`` imports at the top of its content-hash
check. The desktop rebuild died with ModuleNotFoundError and the parent
update only logged "⚠ Desktop build failed (non-fatal)". Same root cause
made the "default: sync failed" line in the skill-sync stage, because
that sync subprocess hit the same missing import.

Fix 1: ``rebuild_venv`` retries with ``--clear``
------------------------------------------------
If ``uv venv`` fails with "already exists" in stderr (which is what uv
prints, and what uv's own hint tells you to fix with --clear), retry
once with ``--clear``. Only this specific failure pattern triggers the
retry — disk-full / interpreter-download failures still surface as
before so we don't mask real problems.

Fix 2: post-install dep verification
------------------------------------
Belt-and-suspenders so future uv resolver quirks (or any other cause of
partial installs) surface immediately instead of hours later in a
downstream subprocess. After ``_install_python_dependencies_with_optional_fallback``
runs, ``_verify_core_dependencies_installed``:

  1. Reads ``[project.dependencies]`` straight from pyproject.toml
     (so we don't trust the venv's stale metadata).
  2. Filters by environment markers via ``packaging.requirements.Requirement``
     so cross-platform exclusions (``ptyprocess ; sys_platform != 'win32'``)
     don't false-positive on Windows.
  3. Runs ``importlib.metadata.version()`` for each remaining dep inside
     the *target* venv interpreter (resolved from ``VIRTUAL_ENV``, not
     ``sys.executable``).
  4. If anything is missing, reinstalls the base group with
     ``--reinstall`` to force re-resolution. If a second probe still
     reports missing deps, force-installs each one with its pinned spec.
  5. Treats final failure as a warning rather than a hard error — a
     single broken-on-PyPI dep shouldn't block an otherwise-successful
     update — but the message points at ``hermes update --force`` and
     names the missing packages so the user knows what's wrong.

Tests
-----
- ``TestRebuildVenv::test_retries_with_clear_when_dir_already_exists`` —
  simulates the rmtree-couldn't-delete-it failure mode and asserts the
  ``--clear`` retry path is taken and succeeds.
- ``TestRebuildVenv::test_does_not_retry_when_first_failure_is_not_dir_exists``
  — guards against masking real failures (disk full, etc.).
- ``test_verify_core_dependencies.py`` — 7 tests covering the happy
  path, the regression (missing pathspec triggers --reinstall), the
  per-package fallback when --reinstall doesn't help, the platform-
  marker filter so Windows doesn't try to install ptyprocess, the
  missing-pyproject noop, and the VIRTUAL_ENV resolver.

Co-authored-by: Kyssta <218078013+kyssta-exe@users.noreply.github.com>

hermes_cli/managed_uv.py

@@ -105,17 +105,40 @@ def rebuild_venv(uv_bin: str, venv_dir: Path, python_version: str = "3.11") -> b
     old venv may point to a Python without FTS5, so we rebuild it with a
     fresh interpreter from the current managed uv.  Returns ``True`` on
     success.
+
+    On Windows, ``shutil.rmtree(..., ignore_errors=True)`` can silently leave
+    the venv directory partially intact when another process is holding an
+    open handle to a file inside it (typical culprits: a running
+    ``hermes.exe`` REPL, the gateway, AV scanners). If we don't notice that
+    and just call ``uv venv``, uv refuses with
+    ``Caused by: A directory already exists at: venv`` and the *whole
+    update* falls back to installing on top of the stale venv — which has
+    historically produced partial installs where a freshly added dependency
+    (e.g. ``pathspec``) silently fails to land. Retry with ``--clear`` to
+    force uv past that condition before giving up.
     """
     if venv_dir.exists():
         print(f"  → Rebuilding venv (old Python may lack FTS5)...")
         shutil.rmtree(venv_dir, ignore_errors=True)
 
-    result = subprocess.run(
-        [uv_bin, "venv", str(venv_dir), "--python", python_version],
-        capture_output=True,
-        text=True,
-        check=False,
-    )
+    def _run_uv_venv(extra_args: list[str]) -> subprocess.CompletedProcess[str]:
+        return subprocess.run(
+            [uv_bin, "venv", str(venv_dir), "--python", python_version, *extra_args],
+            capture_output=True,
+            text=True,
+            check=False,
+        )
+
+    result = _run_uv_venv([])
+
+    # If uv refused because the directory still exists (rmtree above was
+    # blocked by an open file handle, common on Windows), retry with
+    # --clear so uv overwrites it. Match on stderr because uv's exit code
+    # alone doesn't distinguish "dir exists" from real failures.
+    if result.returncode != 0 and "already exists" in (result.stderr or "").lower():
+        print("  → venv dir not fully removed (likely an open file handle); retrying with --clear...")
+        result = _run_uv_venv(["--clear"])
+
     if result.returncode == 0:
         venv_python = venv_dir / ("Scripts" if platform.system() == "Windows" else "bin") / "python"
         py_ver = subprocess.run(