windows: auto-update silently fails when a Runtime Host process survives the app quit (installer cannot clear it)

Summary

quitAndInstall hands off to the NSIS installer without draining the Runtime Host processes the app spawned. A Maka.exe host/candidate process running from the install directory survives the app's quit, the upgrade installer bails out on its app-running handling, and the update silently never applies — the user keeps the old version with no error surfaced. Observed twice on the release-windows-check autoupdate gate; the second occurrence carries full state evidence.

Evidence (run 32382283646, head 6b50c6308, step "Verify automatic update end to end")

The harness drove a real in-app update (check → download → installUpdate handoff at 15:05:13). The app process exited. The upgraded app never appeared; at the 90s mark the state was:

relaunched processes: [{"processId":4648,"name":"Maka.exe","path":"...\installed\Maka.exe"}]
process command lines: "...\installed\Maka.exe ...\app.asar\node_modules\@maka\runtime-host\dist\execution-candidate-main.js
  --root ...\user-data\workspaces\default --expected-root-id b7a77... --startup-attempt-id af63d71b-...
  --initial-connection-timeout-ms 37453 --generation 0.1.11"   CreationDate 15:04:53
backup directory ...\installed.pre-upgrade-backup: present
uninstall registrations: "0.1.11"
Maka.exe on disk: ProductVersion 0.1.11.0

Reading the state:

• The only Maka.exe alive is a Runtime Host execution candidate (--generation 0.1.11), created during the old app's startup and still running 106 seconds after creation — long past its own --initial-connection-timeout-ms 37453 — and well after its parent app quit for the update.
• The upgrade installer did start: the pre-upgrade backup hook (from #3265's installer include, present on this branch) ran and left its backup directory. But the uninstall registration, the on-disk executable, and the uninstaller are all untouched old-version state — so the installer exited on a hookless template path before anything destructive, i.e. in the app-running-check region between .onInit and uninstallOldVersion, with the surviving candidate as the process it could not clear (electron-builder's silent-mode CheckAppRunning/MB_RETRYCANCEL /SD IDCANCEL path ends in Quit).
• Net user-visible behavior: the update downloads, the app quits and relaunches nothing; on next launch the user is still on the old version, with no error anywhere.

A first occurrence with the same signature (relaunch wait finds a Maka.exe, disk still old) was run 32359725716, before the evidence capture existed.

Likely relationship to #3279

An orphaned host/candidate from a previous app generation holding the workspace named-pipe endpoint is also a plausible producer of #3279's host_unresponsive startup failures ("stopped responding during startup" after an upgrade over an existing profile): the new app's election keeps probing an endpoint owned by a stale process. Worth checking both against the same lifecycle fix.

Suggested direction (product decision, not prescribing)

Either quitAndInstall drains Runtime Host children (and any host it owns) before spawning the installer, or host/candidate lifetime is bounded by parent death on Windows (Phase 4 of #2142 already lists "cancellation, parent-death, concurrency, process-drain" evidence as open). The 37s candidate timeout also did not bound this process's lifetime, which may be its own defect.

Evidence grade: CI run log with per-process command lines + template source read (app-running check ordering); not locally reproduced.