[Bug]: "Remove download" fails with EBUSY after Quick Look preview (macOS File Provider)

# [Bug]: "Remove download" fails with EBUSY after a file has been previewed with Quick Look (macOS File Provider)

### ⚠️ Before submitting

- [x] I checked for existing issues (#7832, #9757, #10085, #10517, #10555 — related symptoms, none identifies this cause)
- [x] I can reproduce this reliably

### Summary

On macOS, once a file inside the File Provider domain has been previewed with Quick Look (spacebar in Finder), "Remove download" on that file fails permanently. The Finder dialog shown is:

> **Geen communicatie met een helperapp mogelijk.**
> Probeer de bewerking opnieuw uit te voeren. Als dat mislukt, stop je de app, start je de app opnieuw en probeer je het nogmaals.
>
> *(EN: "Unable to communicate with a helper application.")*

The underlying failure is **`POSIX 16` (`EBUSY`)** from `fileproviderd`, because `QuickLookUIService` leaves an `NSFilePresenter` registration on the item **after the preview window is closed**. The registration is not released on window close and is not released by `SIGTERM` to the service. Only `kill -9` on `QuickLookUIService` clears it, after which eviction succeeds immediately.

This is almost certainly the unexplained "random" eviction failure reported in #7832.

### Steps to reproduce

1. macOS client with Virtual Files / File Provider enabled.
2. In Finder, navigate to a materialised (downloaded) file in the Nextcloud domain — reproduced with a `.mp4`, but not file-type specific.
3. Select the file and press **spacebar** to open Quick Look.
4. **Close the Quick Look window.**
5. Right-click the file → **Remove download**.

### Expected behaviour

The local copy is evicted and the file becomes a placeholder.

### Actual behaviour

Eviction fails with the "Geen communicatie met een helperapp mogelijk" dialog. It fails on every retry, indefinitely. Files in the same folder that were never previewed evict without any problem.

Workaround:

```bash
kill -9 $(pgrep -x QuickLookUIService)
```

After this the exact same "Remove download" succeeds immediately.

### Evidence

`fileproviderd` error at the moment of the failed eviction:

```
2026-08-13 13:48:43.736619+0200 Error fileproviderd: (FileProviderDaemon)
[com.apple.FileProvider:com.nextcloud.desktopclient.FileProviderExt/…]
Eviction of docID(2167678) failed with NSError: POSIX 16 ""
```

`fileproviderctl dump com.nextcloud.desktopclient.FileProviderExt`, taken with **no Quick Look window open**:

```
presenter for S…0.mp4 (__fp/fs/docID(2167678)) by QuickLookUIService[83461]

+ active enumerators:




…

presenter: QuickLookUIService[83461] presenting /…/S…0.mp4
(com.nextcloud.desktopclient.FileProviderExt/…/__fp/fs/docID(2167678))
```

`docID(2167678)` is exactly the item that failed to evict. The presenter is scoped to the single previewed file — all other items report `hasPresenter:no`, so eviction of the parent folder is unaffected.

Notes:

- `lsof` shows **nothing** for the path. The presenter is an XPC-level `NSFilePresenter` registration, not a POSIX file descriptor, so the usual "what's holding this file" check comes back clean and gives no clue.
- `killall QuickLookUIService` (SIGTERM) does **not** clear it — the process survives and keeps the same PID. `kill -9` is required.
- This matches the long-standing Apple bug where Quick Look blocks volume ejection ("The disk wasn't ejected because one or more programs may be using it"), which also only clears with `kill -9`.

### Where the bug sits, and what I'm asking for

The leaked presenter is Apple's defect and I'll file that separately with Feedback Assistant. **The actionable part for the client is the error handling.**

Right now `EBUSY` from `NSFileProviderManager.evictItem` is surfaced as a generic "unable to communicate with a helper application", which points the user at the extension being broken. It cost me a long detour through restarting the client, re-registering the File Provider extension, checking auth, and checking pinning state — none of which was relevant.

Suggestions, in order of value:

1. **Map `EBUSY` / `NSFileProviderError` busy conditions to a distinct message**, e.g. *"This file is currently in use by another application and cannot be removed. Close any preview or app using it and try again."*
2. Optionally name the holding process — it is available via the File Provider APIs and would make this self-service.
3. Consider retrying once after a short delay for genuinely transient busy states, but **not** silently, since this one never resolves on its own.

### Client configuration

- **Nextcloud desktop client:** 34.0.1
- **Operating system:** macOS 26.5.1 (build 25F80)
- **File Provider framework:** 4018.120.24
- **Installation:** official macOS build
- **VFS:** enabled (File Provider based)
- **Server:** Hetzner Storage Share (hosted Nextcloud)

### Related

- #7832 — "MacOS Client with VFS: Sometimes files are not evicted randomly" (closed) — likely the same root cause, reported without a reproduction
- #10517, #10555, #10085, #9757 — adjacent eviction/context-menu issues, different triggers
- #9432 — "Couldn't communicate with a helper application" (open) — same generic error text surfacing for an apparently different trigger (a folder stuck desynced); no repro steps given. Cited here as evidence that this error string is overloaded across multiple root causes, reinforcing the ask below to make it more specific.

Search the macOS File Provider eviction path around NSFileProviderManager.evictItem and the generic "unable to communicate with a helper application" message. Trace how POSIX 16 (EBUSY) and NSFileProviderError busy conditions are surfaced, then add a focused regression test confirming the distinct user-facing message and its guidance to close the application using the file.

Written by the indexing model from the issue text.