[Mac VFS] Large file batch upload causes unrecoverable Finder file locks and orphaned placeholders

### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I have searched for it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

When copying a large batch of big video files (e.g., 15 files totaling around 24 GB, with individual file sizes between 1 GB and 5 GB) into the Nextcloud local directory using Virtual Files (VFS) mode on macOS, the macOS File Provider framework becomes completely unresponsive and desynchronized from the Nextcloud Desktop Client.

While the Nextcloud Desktop Client interface reports a successful state (green checkmark), the macOS Finder continues to display "dotted cloud" icons (indicating pending metadata processing) or "cloud with exclamation mark" icons (indicating interrupted transfer).

During this state:
1. Files become completely locked by the macOS kernel. It is impossible to delete or move the stuck files via the native Finder GUI.
2. The context menu for Nextcloud operations completely disappears on these stuck files or throws a macOS system authentication error ("You need to authenticate before you can access this item.").
3. The file provider eventually unregisters the client on system level, showing the Finder banner "Nextcloud is logged out", despite the desktop app running perfectly fine in the background.

The only way to resolve this severe file lock and clean up the corrupted state is via the macOS Command Line Interface (CLI) by executing `sudo rm ~/Library/CloudStorage/Nextcloud/` to forcefully delete the orphaned placeholder files/hardlinks.

Server-side optimizations (such as adjusting `php.ini` with high `max_execution_time`, `upload_max_filesize`, and using active `php-fpm`) improved the initial throughput, but the underlying macOS File Provider integration still chokes on sequential large file operations and causes unrecoverable local database/link corruption.

### Steps to reproduce

1. Enable Virtual Files (VFS) mode on the Nextcloud macOS Desktop Client.
2. Copy a large batch of large binary files (e.g., 15x MP4 video files, each 1–5 GB) into a Nextcloud directory in Finder.
3. Observe the client processing chunks while macOS starts generating system metadata/thumbnails in the background.
4. If a network fluctuation or temporary webserver timeout occurs during this heavy IO load, the sync pipeline breaks.
5. Notice that the client recovers natively, but the macOS Finder gets stuck permanently with dotted/exclamation-mark clouds. Try to delete the stuck file via Finder – it will fail due to a persistent lock.

### Expected behavior

The macOS File Provider extension should handle transfer interruptions gracefully. If a file fails to sync or times out, it should be queued for a clean automatic retry without corrupting the local file provider database, freezing the Finder GUI, or locking the file system structure to a point where only `sudo rm` via CLI can remove the placeholder.

### Which files are affected by this bug

Multiple large MP4 video files (ranging from 1 GB to 5 GB)

### Operating system

macOS

### Which version of the operating system you are running.

Tahoe (Version 26.6.1)

### Installation method

Official Installer for macOS 13 and later

### Nextcloud Server version

33.0.7

### Nextcloud Desktop Client version

34.0.1

### Did this occur after an update or on a clean installation?

Clean desktop client installation

### Are you using the Nextcloud Server Encryption module?

No

### Are you using an external user-backend?

- [x] Default internal user-backend
- [ ] LDAP or Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell

```

### Additional info

### Environment
* **Operating System:** macOS Tahoe (Version 26.6.1), Architecture: arm64
* **Nextcloud Desktop Client Version:** 34.0.1 (VFS Mode active)
* *Git Revision:* 364596d2caca387c5027a4694890fb79c4177a0f
* *Libraries:* Qt 6.10.2 (built against Qt 6.10.2), OpenSSL 3.6.3 (9 Jun 2026)
* *Platform Plugin:* cocoa
* **Nextcloud Server Version:** 33.0.7 (Production)
* **PHP Version:** 8.4.24 (fpm-fcgi)
* **Webserver:** Apache2

### PHP-FPM Configuration Updates (`/etc/php/8.4/fpm/php.ini`)
The following high-capacity values were applied and the `php8.4-fpm` daemon restarted before initiating the transfer:

* `max_execution_time = 3600`
* `max_input_time = 3600`
* `upload_max_filesize = 16G`
* `post_max_size = 16G`
* `memory_limit = 512M`