Sync permanently stalls after interrupted bulk upload: client loops MKCOL (405) on folders it already created, never uploads their contents

### Bug description

During a large initial upload (~37 GB / ~5,000 files music library), the desktop client's sync became interrupted mid-run. Afterwards the client apparently lost a subset of already-created folders from its local sync journal: on every subsequent sync run it retried `MKCOL` for 16 folders that **already existed on the server** (created by the client itself earlier in the same bulk upload), received `405 Method Not Allowed` ("The resource you tried to create already exists"), flagged them as errors, and **never uploaded their contents**. The affected folders stayed permanently empty on the server while the client showed sync errors. The loop persisted for 11+ hours (across many sync runs and full remote-discovery cycles) with no self-healing.

Bulk uploads (`PUT`) stopped entirely once the loop began — only the 16 failing `MKCOL`s and discovery `PROPFIND`s remained.

### Steps to reproduce

Not deterministically reproducible, but the sequence was:

1. Add a large folder (~37 GB, ~5,000 files, ~840 subfolders) to a synced directory.
2. Client uploads for ~6 h over a high-latency WAN route; folders are created (`MKCOL` → 201) and files uploaded (`PUT` → 201).
3. Sync gets interrupted (~19:00; exact trigger unknown — possibly app restart or connection drop on the high-latency route).
4. From then on, every sync run: `MKCOL` on 16 previously-created (empty) folders → `405` → error → their contents are never uploaded. Remote discovery (`PROPFIND` of the parents, which correctly lists the folders) does not reconcile the client's journal.

### Expected behavior

On `MKCOL` → 405, the client should treat the folder as existing (it is listed in the parent's `PROPFIND` response), record it in the sync journal, and proceed to upload its contents.

### Evidence (server nginx access log, sanitized)

Repeating every sync run, for hours:

```
10.10.0.1 - oliver [13/Aug/2026:04:10:17 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Nazareth/Love%20Hurts HTTP/1.1" 405 ...
10.10.0.1 - oliver [13/Aug/2026:04:53:49 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Keri%20Hilson/In%20A%20Perfect%20World HTTP/1.1" 405 ...
10.10.0.1 - oliver [13/Aug/2026:05:53:38 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Pink%20Floyd/The%20Wall HTTP/1.1" 405 ...
```

User agent: `Mozilla/5.0 (Macintosh) mirall/34.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)`

Upload flatline (PUTs/hour): `13:00–19:59 ≈ 600–1500/h`, from `20:00` onward `0/h`, while `PROPFIND` discovery continued normally (~1,900 requests every 2 h, all `207`).

Server-side state was verified consistent: the 16 folders existed on disk and in `oc_filecache` with correct parent links (a `PROPFIND` on each parent lists them), zero children, no server log entries (sabre answers the 405 silently).

### Workaround that confirms the diagnosis

Deleting the 16 **empty** folders server-side (`occ files:delete`) un-wedged the client immediately: on its next runs it re-created them (`MKCOL` → 201) and began uploading their contents. No client-side reset needed.

### Environment

- Client: Nextcloud desktop 34.0.1, macOS (macos-24.6.0), arm64, standard sync folder
- Server: Nextcloud 34.0.2, nginx + PHP 8.3-FPM, MariaDB, Redis file locking
- Network: high-latency WAN route (VPN/proxy), which likely contributed to the interruption in step 3

### Related issues

- #10028 shows the same `MKCOL`→405 retry-loop symptom but with a different trigger (External Storage roots / virtual files); this report involves plain folders the client itself created earlier in the same sync.
- Distinct from #9846 (trash-bin 404 retry loop), though both are cases of a wedged persistent sync state that remote discovery never reconciles.

Start by tracing the desktop sync path for MKCOL responses and remote-discovery PROPFIND results, using the supplied 405 retry loop and request logs as the reproduction evidence. Done means an already-existing folder is reconciled into the sync state after MKCOL returns 405, its contents are uploaded, and the loop no longer blocks subsequent sync runs.

Written by the indexing model from the issue text.