[Bug]: macOS File Provider does not remove local items after server-side deletion

## Bug description

Nextcloud Desktop in macOS File Provider mode receives a server-side change but does not remove from Finder a file that has already been deleted from the server.

The issue is reproducible with both fully downloaded files and cloud placeholders whose contents have never been downloaded to the Mac.

## Environment

- macOS: 26.6.2, Apple Silicon
- Nextcloud Desktop Client: 34.0.2
- Installation method: official installer for macOS 13 and later
- Mode: File Provider / Virtual Files
- Nextcloud Server: 33.0.7.1, Nextcloud AIO
- notify_push: installed and working
- Server-side encryption is not used for the test files

## Steps to reproduce

1. Create a test Markdown file directly on the server through WebDAV.
2. Wait for the file to appear in Finder on the Mac.
3. Do not open the file. Use `fileproviderctl evaluate` to confirm:
- `isDownloaded = 0`
- `isKeepDownloaded = 0`
- `isUploaded = 1`
- `isTrashed = 0`
4. Delete the file directly from the server through WebDAV.
5. Confirm that the server returns `DELETE 204`.
6. Check the server path again and confirm that it returns `404`.
7. Observe the file in Finder.

## Expected behavior

After the server-side deletion, the local placeholder or downloaded file should disappear from Finder.

## Actual behavior

The file remains in Finder indefinitely.

After the server-side deletion, `fileproviderctl evaluate` continues to report the previous item:

- the previous `itemIdentifier`;
- `isDownloaded = 0` or `1`, depending on the test;
- `isUploaded = 1`;
- `isTrashed = 0`;
- the previous version/ETag.

Restarting Nextcloud Desktop, restarting FileProviderExt, and fully rebooting macOS do not resolve the problem.

## Additional findings

- Creating a file on the server propagates to the Mac, sometimes after a delay of approximately one minute.
- Modifying a file on the server propagates to the Mac.
- Creating, modifying, and deleting a file on the Mac propagates correctly to the server.
- Only the direction “server-side deletion → removal of the local File Provider item” fails.
- Disabling Keep Downloaded does not resolve the problem.
- The issue is reproducible even with `isDownloaded = 0`, so it does not depend on content materialization.
- The file is confirmed to be absent from the server.
- notify_push delivers the server-side change to the Mac.

## Impact

On systems with multiple computers, the stale item can present an incorrect view of the shared folder state. It may also create a risk of conflicts or re-uploading the item from another computer.

## Related issues

- #9553 — File provider extension does not propagate remote folder deletion
- #10556 — macOS File Provider keeps stale folder metadata
- #10070 — New items from other devices do not appear
- #10252 — Correct Remote Change Propagation to File Provider Framework

## Questions for the developers

Could this be a regression of #9553 or an uncovered path in the remote-change propagation mechanism addressed by #10252?

Is a corresponding fix planned for 34.0.3?

Reproduce the server-side deletion flow using the WebDAV steps and inspect the result with `fileproviderctl evaluate`. Read related issues #9553 and #10252 for the remote-change propagation context, then trace the File Provider path handling the notified deletion. Done means both downloaded files and cloud placeholders disappear from Finder after the server-side deletion.

Written by the indexing model from the issue text.