[Bug][Windows] Check for updates fails with EPERM renaming installations.json.tmp

## Description

Clicking **Check for updates** for a local standalone ComfyUI installation consistently fails on Windows with an `EPERM` error while replacing `installations.json`.

The installation itself still works and the UI reports that ComfyUI is up to date, but every manual update check ends with the error dialog.

## Environment

- Comfy Desktop: **1.0.29**
- ComfyUI installation: **Stable v0.28.2**
- Electron: **40.4.1**
- OS: **Windows 11 Home, x64, version 10.0.26200 (build 26200)**
- Filesystem: **NTFS**
- Application installed on a non-system drive
- User data: `%APPDATA%\Comfy Desktop`

## Steps to reproduce

1. Launch Comfy Desktop.
2. Open the local standalone ComfyUI installation.
3. Open the **Update** tab.
4. Click **Check for updates**.
5. Wait approximately 2–3 seconds.

## Actual behavior

The following dialog appears every time:

```text
EPERM: operation not permitted, rename
'%APPDATA%\Comfy Desktop\installations.json.tmp' ->
'%APPDATA%\Comfy Desktop\installations.json'
```

Reproduction rate: **100% across repeated attempts**.

## Expected behavior

The update check should complete and report whether the installed ComfyUI version is current, without failing to persist installation metadata.

## Diagnostics performed

- The user owns `%APPDATA%\Comfy Desktop` and has `FullControl` on both the directory and `installations.json`.
- Neither the directory nor the file is read-only.
- `installations.json` is valid JSON.
- `installations.json` and `installations.json.bak` are byte-identical (same SHA-256), so no corruption was observed.
- No stale `installations.json.tmp` remains after the failure; it is cleaned up.
- Windows Defender Operational logs contain no corresponding blocked-access event.
- Before clicking **Check for updates**, `installations.json` can be opened with an exclusive, non-shared file handle.
- Immediately after the error, repeated exclusive-open probes fail because the file is in use by another process. The lock persists after dismissing the error dialog and after closing the instance-selection popup.
- The current `app.log` is empty and does not record this error.

## Relevant shipped implementation

The source bundled in `app.asar` shows that installation saves call `writeFileSafeAsync()` in `src/main/lib/safe-file.ts`. It writes to a fixed `.tmp` path and retries `fs.promises.rename()` three times, with delays of 100 ms, 200 ms, and 300 ms. The target remains locked beyond that retry window in this environment, after which the temporary file is unlinked and the `EPERM` is surfaced.

This may be a persistent file-handle leak/race in the update-check path, or a Windows file-indexer/antivirus lock that needs a longer/backoff-based replacement strategy. The important observable behavior is that the target is exclusively accessible before the update check and becomes persistently locked immediately after it.

## Data safety

No installation data appears to be lost or corrupted. The existing JSON and backup remain valid and identical.

Start with src/main/lib/safe-file.ts and its writeFileSafeAsync() callers in the update-check path; reproduce the Windows failure while observing the temporary-file rename and file lock. Trace which handle or race keeps installations.json locked, then verify that Check for updates completes and persists installation metadata without the EPERM dialog.

Written by the indexing model from the issue text.