Question: Should model downloads support exFAT filesystems?

### Question

Does Comfy Desktop intend to support model directories on exFAT/FAT32 filesystems? If so, what finalization strategy would maintainers prefer when hard links are unavailable?

### Context

- Comfy Desktop: 1.0.46
- OS: Windows 11
- Model root: an `E:` drive formatted as exFAT
- Download source: the in-app managed model downloader

The model download reaches its expected byte count, but the final step fails with:

```text
Failed to move download to final location
```

The complete staged file and sidecar remain in the correct model directory:

```text
.safetensors.part
.safetensors.part.dl-meta
```

For one reproduced download, the `.part` size was exactly equal to the sidecar's `expectedSize` (`1,956,193,000` bytes), the final path did not exist, and the drive had ample free space and writable permissions.

### What appears to happen

`installStagedAtFinal()` first calls `fs.linkSync(stagingPath, finalPath)`. Hard links are not supported by exFAT. A direct test using the current repository code on the real exFAT volume produced:

```text
EISDIR: illegal operation on a directory, link '.safetensors.part' -> '.safetensors'
```

This is notable because `LINK_UNSUPPORTED_CODES` anticipates `EPERM` for Windows exFAT/FAT32, but this Node/libuv combination reports `EISDIR`. Even for recognized capability errors, `installStagedAtFinal()` currently throws `atomic no-replace install is not supported by this filesystem` and retains the staged bytes.

### Reproduction

1. Configure `modelsDirs` on an exFAT volume.
2. Start a model download from a built-in template/missing-model dialog.
3. Wait until the progress reaches 100%.
4. Observe that the `.part` file matches `expectedSize`, but finalization fails and no final model file is created.

### Questions for maintainers

1. Is storing Desktop model directories on exFAT/FAT32 intentionally unsupported?
2. If these filesystems should be supported, would an exclusive `wx` claim followed by same-directory rename be an acceptable fallback for known hard-link capability errors? Startup scanning already contains recovery handling for a crashed zero-byte claim marker.
3. If the no-clobber guarantees make that fallback unacceptable, should Desktop detect unsupported filesystems before downloading and show a clear validation error instead of downloading the entire model first?

This may also explain the `EISDIR` finalization error reported in #1450; the error can occur on exFAT even when both the staging and final paths include the correct category and filename.

Start at installStagedAtFinal() and inspect LINK_UNSUPPORTED_CODES, then compare the startup-scanning recovery handling for a crashed zero-byte claim marker. Reproduce the finalization failure on exFAT using the provided model and expectedSize details, including the EISDIR result. Done means the project has a maintainer-approved handling or validation policy for unsupported filesystems while preserving no-clobber guarantees.

Written by the indexing model from the issue text.