fix(desktop): stop telling installer users they installed Hermes from the command line

[stantheman0128]

What does this PR do?

Windows users who installed Hermes with an official installer get a false dialog when they click Update: "You installed Hermes from the command line, so updates run there too." (#66095, reported with filesystem evidence.)

Root cause: the manual fallback in applyUpdates() (apps/desktop/electron/main.ts) treats a missing staged updater (HERMES_HOME/hermes-setup.exe) as proof of a CLI install. Two installer flows land in that branch:

• The electron-builder NSIS/MSI desktop installer puts Hermes.exe outside the managed checkout, and its first-launch bootstrap (bootstrap-runner.ts driving install.ps1) never stages hermes-setup.exe. Only the Tauri Hermes-Setup installer stages that binary (paths::copy_self_to_hermes_home). This matches the reporter's evidence exactly: repo cloned under %LOCALAPPDATA%\hermes\hermes-agent, no hermes-setup.exe, no .install_method in HERMES_HOME.
• The Tauri installer's self-copy is best-effort (bootstrap.rs logs a warning and continues on failure), so that flow can also end up without the staged updater.

This PR tells the two cases apart and shows an honest explanation. The recovery command (branch-pinned hermes update) stays the same because it works for installer users too: install.ps1's Set-PathVariable persists the venv Scripts dir to the user PATH.

Detection lives in a new pure module, apps/desktop/electron/update-install-kind.ts:

• a packaged desktop whose process.execPath is outside resolveUpdateRoot() is installer-deployed (a CLI hermes desktop launch always runs the packed exe from <checkout>/apps/desktop/release/*-unpacked/, per _desktop_packaged_executable in hermes_cli/main.py);
• HERMES_HOME/logs/bootstrap-installer.log is a Hermes-Setup breadcrumb, created by init_logging() at installer startup, so it exists even when the self-copy failed;
• everything else keeps today's CLI message, including unpackaged dev runs.

Scope notes: this PR does not make the installers stage hermes-setup.exe (a packaging pipeline change; the NSIS shell would have to ship the separate Tauri updater binary), and it does not touch the backend's .install_method detection (#61827). The adjacent updater PRs solve different failure modes: #37748 validates a staged updater that exists, #61093 finds one staged in a different Hermes home. Here the updater never existed.

Related Issue

Fixes #66095

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• apps/desktop/electron/update-install-kind.ts (new): pure classifyWindowsManualUpdate() with win32 path-containment semantics (case-insensitive, both separators, no sibling-prefix false positives).
• apps/desktop/electron/update-install-kind.test.ts (new): 7 unit tests covering the NSIS layout from the issue, the failed-self-copy Tauri case, case/separator variance, sibling-prefix dirs, dev runs, and missing inputs.
• apps/desktop/electron/main.ts: the manual fallback computes installKind and carries it on the apply result and the hermes:updates:progress payload; the log line now records which kind was detected.
• apps/desktop/src/global.d.ts, apps/desktop/src/store/updates.ts: thread installKind through UpdateApplyState on both the result and progress paths.
• apps/desktop/src/app/updates-overlay.tsx: ManualView shows the missing-updater body when installKind === 'installer'.
• apps/desktop/src/i18n/{types,en,zh,zh-hant,ja}.ts: new updates.manualBodyMissingUpdater string.
• apps/desktop/src/store/updates.test.ts: 3 store cases (cli kind, installer kind, and null default when an older main process omits the field).

How to Test

1. On Windows, install Hermes with the official desktop installer (or delete %LOCALAPPDATA%\hermes\hermes-setup.exe from a Hermes-Setup install to simulate the failed self-copy).
2. Open Hermes and click the update button when an update is available.
3. Before: the dialog claims you installed from the command line. After: the dialog says the install is missing its updater helper and offers the same hermes update command.

Verification I actually ran (Windows 11, this branch):

$ npx vitest run --project electron update-install-kind
 Test Files  1 passed (1)
      Tests  7 passed (7)

$ npx vitest run --project ui src/store/updates.test.ts
 Test Files  1 passed (1)
      Tests  27 passed (27)

$ npm run typecheck
> tsc -p . --noEmit && tsc -p tsconfig.electron.json --noEmit
(clean)

$ npx eslint electron/update-install-kind.ts electron/update-install-kind.test.ts electron/main.ts \
    src/store/updates.ts src/store/updates.test.ts src/app/updates-overlay.tsx src/global.d.ts \
    src/i18n/en.ts src/i18n/zh.ts src/i18n/zh-hant.ts src/i18n/ja.ts src/i18n/types.ts
(clean)

$ npx prettier --check electron/main.ts electron/update-install-kind.ts electron/update-install-kind.test.ts \
    src/app/updates-overlay.tsx src/global.d.ts src/i18n/en.ts src/i18n/ja.ts src/i18n/types.ts \
    src/i18n/zh-hant.ts src/i18n/zh.ts src/store/updates.test.ts src/store/updates.ts
Checking formatting...
All matched files use Prettier code style!

(An earlier revision of this branch had one log line in main.ts over the Prettier print width; the last commit wraps it, and the check above is from the final tree.)

A full vitest run in apps/desktop shows 6 failing test files (scripts/before-pack.test.mjs, scripts/stage-native-deps.test.mjs, electron/update-relaunch.test.ts, electron/windows-hermes-path.test.ts, src/app/messaging/index.test.tsx, src/app/skills/index.test.tsx). I stashed my changes and re-ran on a clean origin/main checkout: the same 6 files fail there, so they are pre-existing on this machine and unrelated to this change.

Honest boundary: I verified the detection and dialog logic at the unit level plus typecheck and lint. I did not build the NSIS installer artifact or drive a packaged desktop end to end; the classifier tests encode the exact filesystem layouts the two install flows produce.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate (checked fix: harden desktop updater handoff #37748, fix(desktop): harden update handoff home resolution #61093, Fix desktop updater runtime cleanup #40558, fix(desktop): detect stale builds and surface rebuildNeeded in update UI #42382; none address installer misdetection)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass (not run: this PR touches only apps/desktop TypeScript, no Python; I ran the desktop vitest projects, tsc, and eslint instead, output above)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11 (unit tests, typecheck, lint; no packaged end-to-end run, see boundary note above)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A (behavior documented in code comments; no docs page describes the manual dialog)
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — the changed branch is Windows-only (POSIX takes the in-app update path before it), and the classifier deliberately uses win32 path semantics
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

See the command output in "How to Test" above.

Written by Stan Shih (stantheman0128) with Claude Code assisting on implementation and tests.

[tonydwb]

Code Review Summary

Verdict: Approved

Looks Good

• Fixes incorrect messaging: desktop installer was telling users they installed from command line even when they used the installer
• Clean fix updating the conditional text
• No security concerns

---

Reviewed by Hermes Agent

[teknium1]

Thanks for tracing the installer layouts and keeping the change local to the desktop update seam.

Problems

• The new installKind tests cover the updates.apply() result path, but not the separately changed progress path. Current main subscribes through apps/desktop/electron/preload.ts:256-261 and applies events in apps/desktop/src/store/updates.ts:616-637; please add a manual-progress event test that verifies installKind: 'installer' reaches $updateApply.

Suggested changes

• Keep the existing classifier tests, and add the event-path test above so both Electron-to-renderer transport paths are covered.

Current main still unconditionally calls this a CLI install in apps/desktop/electron/main.ts:2448-2479 and always renders the CLI copy in apps/desktop/src/app/updates-overlay.tsx:300, so the reported premise remains live. This is an automated hermes-sweeper review.

[stantheman0128]

Thanks for the catch on the progress-event path.

Added a startUpdatePoller test that feeds a stage: 'manual' progress payload with installKind: 'installer' through onProgress and asserts it lands on ``. Existing apply()-result and classifier tests are unchanged.

Evidence (from apps/desktop):

npm test -- src/store/updates.test.ts electron/update-install-kind.test.ts

Test Files  2 passed (2)
     Tests  35 passed (35)

[stantheman0128]

Closing this P3 installer-copy PR so review attention can go to higher-impact Windows/desktop fixes we still have open.