Windows: the installer first run always fails - it detects its own install as z.ai and closes it; second run succeeds (also breaks the in-app Update button)

Description

On Windows, the first install/update attempt of ZCode Desktop always fails: the installer detects its own install as z.ai and tries to close it, killing its own installation mid-flight. Running the installer a second time always succeeds. The pattern is 100% reproducible on this machine and is the reason the in-app Update button fails — the update flow spawns the install step, which self-terminates on its first run.

Steps to Reproduce

1. Have ZCode Desktop installed on Windows (observed on 3.10.1.6272, per-user install under %LOCALAPPDATA%\Programs\ZCode).
2. Trigger an update — either the in-app Update button, or run the downloaded ZCode-<version>-win-x64.exe directly.
3. First attempt: the install/update aborts. During the attempt the installer identifies its own install as z.ai and attempts to close it — terminating itself/its own install chain.
4. Run the same installer again: succeeds, every time.

Expected Behavior

The first install/update attempt completes without self-termination; the in-app Update button applies the update on the first try.

Actual Behavior

• First attempt: always fails (self-close of its own install/process).
• Second attempt: always succeeds.
• Net effect: the Update button never works on the first try.

Environment

• OS: Windows 11 (build 10.0.26200), x64
• App: ZCode Desktop 3.10.1.6272 (installed 3.10.1; ProductName: ZCode, registry DisplayName: ZCode 3.10.1)
• Install type: per-user, NSIS (Uninstall ZCode.exe present), updater = electron-updater (cache dir %LOCALAPPDATA%\@zcodedesktop-updater)

Evidence from this machine (most recent failure)

• %LOCALAPPDATA%\@zcodedesktop-updater\installer.exe — downloaded 2026-08-31 00:17
• %LOCALAPPDATA%\@zcodedesktop-updater\current.blockmap and pending\ — touched 2026-08-31 03:01, i.e. the failed attempt minutes before this report
• pending\ZCode-3.10.2-win-x64.exe + pending\update-info.json (isAdminRightsRequired: false) — the 3.10.2 update is staged but never applies via the button; it only lands on the second manual run

Likely mechanism (reporter's read — please verify against the NSIS/electron-updater step)

This looks like a self-match in the installer's close-running-processes step: the process enumeration matches the installer's own process (or its parent chain when spawned via quitAndInstall() from the running app) against the product/app match string, so it kills its own install. The second run succeeds because the first run already closed the original instance, so nothing self-matches anymore. If the match logic string-compares process names against a z.ai-style product identifier, an exact/prefix match that excludes the installer's own PID should fix it.

Start by tracing the electron-updater quitAndInstall flow and the NSIS close-running-processes step, using the staged installer.exe and pending update files described in the report. Reproduce the first-run failure and verify that the installer no longer matches or terminates itself, then confirm the in-app Update button applies the update successfully on the first attempt.