Failure downloading one stale remote entry cancels and blacklists an unrelated HTTP 200 download

### ⚠️ 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 multiple files are downloaded concurrently, a failure for one stale remote
entry cancels an unrelated valid download.

The valid file exists on the server and its GET request receives HTTP 200 OK.
However, shortly after another file returns HTTP 503 with "file doesn't seem
to exist", the valid request is cancelled with QNetworkReply::OperationCanceledError.

The client then records a normal error against the valid file and adds it to
the sync journal blacklist. Repeated sync attempts increase its retry count,
preventing a valid file from completing.

The stale server file-cache entry is a server-side consistency problem, but
failure isolation and blacklisting of the unrelated file appear to be a
desktop-client sync-engine problem.

### Steps to reproduce

1. Have a remote folder containing:
- A valid large file that can be downloaded normally.
- A stale entry returned by WebDAV discovery whose content GET returns
HTTP 503 / "file doesn't seem to exist".
2. Configure a normal desktop sync folder with virtual files disabled.
3. Start synchronization so both files are downloaded concurrently.
4. Observe the stale file fail.
5. Observe the valid HTTP 200 download get cancelled and blacklisted.
6. Retry synchronization and observe the valid file repeatedly fail in the
same way.

### Expected behavior

The error should be recorded only for the stale or unavailable file.

Downloads of unrelated valid files should continue, or at minimum be retried
as intentionally interrupted transfers without being blacklisted as failures.

### Which files are affected by this bug

valid-large-video.mp4

### Operating system

Windows

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

Windows 11 Pro

### Installation method

Official Windows MSI

### Nextcloud Server version

33.0.6.2

### Nextcloud Desktop Client version

34.0.1

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

Minor version update (i.e. 33.0.0 → 33.0.1)

### 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
2026-08-13 00:34:29.860
missing-photo.jpg: HTTP status 503, Service Unavailable

2026-08-13 00:34:29.861
Could not complete propagation of missing-photo.jpg with FatalError:
"file doesn't seem to exist"

2026-08-13 00:34:29.904
Request for valid-large-video.mp4 finished

2026-08-13 00:34:29.904
Network request error "Operation canceled"
HTTP status 200, httpReason "OK"

2026-08-13 00:34:29.904
QNetworkReply::OperationCanceledError

2026-08-13 00:34:29.905
Setting blacklist entry for valid-large-video.mp4

This sequence has occurred repeatedly. The valid file's blacklist retry count
eventually reached 5.
```

### Additional info

_No response_

The report names no source file or test. Reproduce concurrent downloads with one stale WebDAV entry and one valid large file, then trace the desktop sync engine's QNetworkReply cancellation, error recording, and sync-journal blacklist handling. Done means the stale file alone receives an error and unrelated HTTP 200 downloads continue or are retried without blacklisting.

Written by the indexing model from the issue text.