fix(desktop): read HERMES_HOME from the Windows registry when env is stale

[lEWFkRAD]

What does this PR do?

On Windows, Hermes Desktop shows "No inference provider configured" even when HERMES_HOME and the provider/.env are correctly configured and the CLI works with the identical setup (#45471).

Root cause: a GUI app launched from Explorer inherits the environment block captured at login, so a HERMES_HOME set via setx after login is absent from process.env — even though a fresh shell (and the CLI) sees it immediately. The desktop's resolveHermesHome() (electron/main.cjs) consulted only process.env.HERMES_HOME, so it silently fell back to %LOCALAPPDATA%\hermes, where there's no config/.env. The spawn itself is fine — startHermes() already pins HERMES_HOME and inherits process.env — but it pins the wrong value. Because everything downstream (both .env lookup locations and the Settings panel) resolves relative to that home, all three configuration paths the reporter tried failed at once.

The repo already acknowledges this fragility — main.cjs notes "install.ps1 sets HERMES_HOME via setx; the desktop can't reliably do that, so we set it inline for every spawn." This PR closes the remaining gap.

Related Issue

Fixes #45471

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• apps/desktop/electron/windows-user-env.cjs (new) — dependency-free helper reading a User-scoped env var from HKCU\Environment via reg query, with reg-output parsing and %VAR% expansion. Pure functions + an injectable exec so it's unit-testable without spawning, mirroring backend-env.cjs.
• apps/desktop/electron/main.cjs — resolveHermesHome() now consults readWindowsUserEnvVar('HERMES_HOME') on Windows when process.env.HERMES_HOME is unset, before the %LOCALAPPDATA%\hermes default. Gated: Windows-only, fallback-only — the common path (env var present, or non-Windows) is untouched.
• apps/desktop/electron/windows-user-env.test.cjs (new) — unit tests for the parser, the %VAR% expander, and the reader (off-Windows no-spawn, query shape, expansion, reg-exits-nonzero, empty value).
• apps/desktop/package.json — register the new test in test:desktop:platforms (scripts-only; no dependency/lockfile change).

How to Test

$ cd apps/desktop
$ node --test electron/windows-user-env.test.cjs
ℹ tests 10
ℹ pass 10
ℹ fail 0

Verified on Windows 11 against the live registry — the helper reads real HKCU\Environment values, including the exact target var:

$ node -e "const m=require('./electron/windows-user-env.cjs'); console.log(m.readWindowsUserEnvVar('HERMES_HOME'))"
C:\Users\<user>\AppData\Local\hermes

This confirms the mechanism picks up a setx-configured HERMES_HOME that a GUI-launched process.env would miss.

Verification scope (full disclosure): I verified the registry-read mechanism on real Windows 11 and the parse/expand/gating logic via unit tests. I did not reproduce the full end-to-end GUI scenario (stale Explorer env → desktop launch → "No inference provider"), which needs a contrived multi-session Windows setup; that path is reasoned from the code (resolveHermesHome → startHermes env pin) and the repo's own propagation comment. The fix is gated to the Windows fallback case, so worst case it's a no-op.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(desktop): …)
• I searched for existing PRs to make sure this isn't a duplicate (none reference Windows fails to read OPENROUTER_API_KEY / HERMES_HOME #45471)
• My PR contains only changes related to this fix
• I've run pytest tests/ -q and all tests pass — N/A: JS/Electron change. Ran node --test electron/windows-user-env.test.cjs → 10 pass, and npm run test:desktop:platforms → 164/165 (the one failure, desktop background child processes opt into hidden Windows consoles in windows-child-process.test.cjs, is pre-existing on main and unrelated to this change — it's untouched here)
• I've added tests for my changes (the new windows-user-env.test.cjs)
• I've tested on my platform: Windows 11 (unit tests + live HKCU\Environment read)

Documentation & Housekeeping

• I've updated relevant documentation — N/A: no user-facing surface; the helper is documented in-file
• I've updated cli-config.yaml.example if I added/changed config keys — N/A: no config keys
• I've updated CONTRIBUTING.md/AGENTS.md if I changed architecture/workflows — N/A
• I've considered cross-platform impact (Windows, macOS) — fix is gated Windows-only and fallback-only; non-Windows and the env-var-present path are byte-for-byte unchanged
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

See How to Test above (node --test output + live registry read).

[austinpickett]

This was merged in with #46772

[lEWFkRAD]

This was merged in with #46772

Well, isn't that nice