A Windows venv broken mid-update (e.g. python-dotenv missing after a partial
pip install) still has python.exe + Scripts\hermes.exe on disk.
unwrapWindowsVenvHermesCommand() returned that interpreter with no probe --
bypassing even the caller's --version smoke test -- so every recovery action
(Retry, Repair install, Use local gateway) re-resolved the same dead backend:
ModuleNotFoundError: No module named 'dotenv', same overlay, forever.
- unwrapWindowsVenvHermesCommand now runs canImportHermesCli() on the venv
python (checkout on PYTHONPATH, mirroring isActiveRuntimeUsable) and
returns null on failure so the resolver falls through to the bootstrap
installer, which actually repairs the venv.
- hermesRuntimeImportProbe() adds 'import dotenv' -- the first third-party
import on the CLI boot path (hermes_cli/env_loader.py) -- so a venv missing
python-dotenv fails the probe everywhere it's used (isActiveRuntimeUsable,
system-python rung, and the new unwrap gate).
- Regression tests: probe content + source assertion that the unwrap path
probes and falls through.