fix(desktop): hide PowerShell windows during Windows update and fix update race condition

[aEgoist]

Summary

Fixes two related issues in the Windows update flow (apps/desktop/electron/main.ts) that cause multiple PowerShell windows to appear on screen during an update. See #61898.

Problems

1. Visible PowerShell windows: When spawning hermes-setup.exe in applyUpdates and handOffWindowsBootstrapRecovery, windowsHide was set to false, so PowerShell windows became visible.

2. Race condition: applyUpdates used a finally block that reset updateInFlight to false immediately on return. But the app waits UPDATE_HANDOFF_DWELL_MS (2.5s) before quitting. In that window a re-triggered update saw updateInFlight === false and spawned another updater process producing many stacked PowerShell windows.

Changes

• Set windowsHide: true in both spawn sites.
• Replace the finally block with a catch block so updateInFlight is only reset on error, keeping the guard held through the 2.5s quit dwell on the success path.
• Reset updateInFlight explicitly on the POSIX in-app and manual-command early-return paths (which do not quit the app).
• Add an updateInFlight guard to handOffWindowsBootstrapRecovery to prevent concurrent recovery hand-offs.

Notes

The Rust updater (apps/bootstrap-installer/src-tauri/src/update.rs) already uses CREATE_NO_WINDOW (0x08000000); this change brings main.ts in line with that behavior.

[giggling-ginger]

Review

This PR correctly targets #61898 (Windows update PowerShell windows + updateInFlight race during the 2.5s handoff dwell). The direction is right, but it is not ready to merge as written: it introduces a soft-failure lockout and breaks an existing desktop electron test.

What looks good

• Success-path race: replacing finally with catch so updateInFlight stays true through UPDATE_HANDOFF_DWELL_MS before app.quit() is the right fix for stacked updater spawns.
• Explicit updateInFlight = false on the POSIX in-app and manual-command early returns (those paths do not quit).
• windowsHide: true on both hermes-setup handoff sites is consistent with the Tauri updater's CREATE_NO_WINDOW approach for console children.
• Guard on handOffWindowsBootstrapRecovery against concurrent handoffs.

Blocking issues

1. Soft-failure path never clears updateInFlight (regression)

!lock.unlocked returns { ok: false, ... } without throwing. Under the old finally, the flag was always cleared. Under the new catch, it is not.

After one aborted update (another process holds the venv), every later applyUpdates call hits:

if (updateInFlight) {
  throw new Error('An update is already in progress.')
}

…for the rest of the process lifetime, even though the handoff never happened and the app is still running.

Please reset updateInFlight = false on every non-handoff return inside the try (at least the lock-abort path). Same class of issue on handOffWindowsBootstrapRecovery: if spawn / releaseBackendLockForUpdate throws after updateInFlight = true, there is no catch/finally to clear the flag.

2. Existing test still requires windowsHide: false — and now fails

PR only touches main.ts and does not update:

apps/desktop/electron/windows-child-process.test.ts

test('intentional or interactive desktop child processes stay documented', () => {
  assert.match(source, /windowsHide: false/)
  ...
})

After this change, main.ts has zero windowsHide: false sites, so that assertion fails.

Tests run locally

Suite	Result
electron/windows-child-process.test.ts (via tsx --test)	FAIL — 4 pass / 1 fail
Failing test	intentional or interactive desktop child processes stay documented — assert.match(source, /windowsHide: false/)
src/store/updates.test.ts (vitest)	PASS (25/25) — renderer/store only; does not exercise main-process handoff
GitHub checks on this PR	none reported at review time

No Windows E2E was run here (Linux host). The race + windowsHide behavior still needs a packaged Windows smoke if possible.

Suggested fix before merge

1. On lock-abort (and any other “stay alive” return), set updateInFlight = false before returning.
2. Wrap recovery handoff in try/catch (or try/finally) so exceptions clear the flag.
3. Update windows-child-process.test.ts to assert the two handoff sites use windowsHide: true (or drop the blanket windowsHide: false grep if those were the only intentional sites).
4. Re-run npm run test:desktop:platforms (or at least tsx --test electron/windows-child-process.test.ts).

Until (1) and (3) land, this does not fully close #61898 without risk of bricking in-session retries and red CI on the desktop platform suite.

[teknium1]

Thanks for targeting both updater-console visibility and the success-path handoff race. The premise is still present on current main: applyUpdates() and recovery both use windowsHide: false (apps/desktop/electron/main.ts:2599, 2677), and applyUpdates() clears its guard in finally before the 2.5-second dwell (2623-2629).

Problems

• Replacing finally with catch leaves the normal lock-abort return (apps/desktop/electron/main.ts:2572-2585) with updateInFlight === true. Because that path returns rather than throws, retries then fail at the guard in applyUpdates().
• apps/desktop/electron/windows-child-process.test.ts:105 requires windowsHide: false. This PR changes the only two such occurrences, so the existing test no longer describes the intended behavior and will fail.

Suggested changes

• Clear the guard on every path that keeps the application alive, including the !lock.unlocked return; retain it only once a quit handoff is scheduled.
• Update the child-process test to assert windowsHide: true at both updater handoff sites, and add coverage for a lock-abort followed by a retry.
• Give the new recovery guard equivalent failure cleanup.

Automated hermes-sweeper review.

[teknium1]

!lock.unlocked returns { ok: false, ... } instead of throwing, so this catch does not clear the guard on that path. Clear updateInFlight before every non-handoff return (including the lock-abort return), otherwise all later update attempts in this still-running process fail as already in progress.