[Bug]: 3.15.0 does not handle local write restriction correctly for read-only (group) folders

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github, other reports differ.
- [x] Nextcloud Server and Desktop Client are **up to date**.
- [x] I agree to follow Nextcloud's Code of Conduct.

### Bug description

My local sync client has permission issues with a group folder to which the user is only granted read-only access.

On Linux, macOS and Windows, I get an error when removing a subfolder from a read-only folder in sync settings.

If another user with write access deletes a file or folder within such a synced read-only folder, windows correctly deletes that file, macOS yields an "unknown error: 513" (and re-syncs as usual but then yields the error again) while the sync client constantly syncs on Linux (see screencast below).

### Steps to reproduce

My local user L account syncs a to a Nextcloud 28.0.12 using Desktop 3.15.0. One of the synced folders is a group folder F. The Nextcloud user U has restricted access (read-only) to that folder F. F contains a sub-folder S.

#### Issue 1: (De)Selecting folders in Nextcloud Desktop settings (Linux, Windows, macOS)

If I deselect S in the Nextcloud Desktop settings and apply, a sync is triggered. That (and subsequent) syncs yield an error: "S: access denied":


I can fix that by manually re-adding write access for L to F and S (`chmod u+w F F/S`). Then, the sync client deletes the folder *and it's read-only (`444`) file!* and resets the access mode of F to `555`.

If I now re-select S in the Nextcloud Desktop settings and apply, a sync is triggered and S is added correctly (with `555`). If I had manually added write access to F beforehand, it also is reset to `555` for F upon adding a subfolder.

#### Issue 2: External deletion of a file/folder within a read-only folder (Linux and macOS)

If some other Nextcloud user V (with regular write access) changes any file within F, these changes are written correctly to the local file, although that file is read-only. However, when V deletes a file or folder within F, my sync client enters an endless re-sync loop on Linux:

https://github.com/user-attachments/assets/4d704c13-ccac-45c2-b8c9-e4748ac4107a

On macOS the deletion triggers an "Unknown error: 513" and runs into that again on each sync.
On Windows, the remote deletion works as expected: the local (read-only) file is deleted correctly.

The only way I found to remedy this situation was to manually recursively give write access to all folders from S to the deleted file/folder. Then, the sync client deletes that file/folder and removes write access again.

### Expected behavior

It seems to be reasonable to deny write access to files on a system level, but the sync client should be able to override them. It does that for synced files but the devs (and tests!) seem to have missed folders and the deletion scenario. The user must be able to deselect subfolders and sync incoming deletions without errors.

### Which files are affected by this bug

test.md

### Operating system

Linux

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

EndeavourOS = Arch Linux, up-to-date

### Package

Distro package manager

### Nextcloud Server version

28.0.12

### Nextcloud Desktop Client version

3.15.0

### Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 3.3.6 to 3.4.0)

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

Encryption is Disabled

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

- [x] Default internal user-backend

### Additional info

I cannot attach the Linux Debug Logs since this is my regular business PC and the files within the Debug ZIP cannot easily reduced to one cloud instance. Thus the files would yield information on clouds of my customers.

But I captured just the cloud I tested with on Windows and macOS now:

[3.15.0-W11.zip](https://github.com/user-attachments/files/17957551/3.15.0-W11.zip)
[3.15.0-mac.zip](https://github.com/user-attachments/files/17957658/3.15.0-mac.zip)