[Bug]: Top-most level file permissions are enforced recursively for nested shares

### ⚠️ 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've searched 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

Assuming a user share by UserA of the "Documents" directory where read-only access is given to another UserB, and if a nested share is created in "Documents/somefolder" with read-write permissions given to UserB. If UserB attempts to access the folder locally via "\~/Nextcloud/Shared/Documents/somefolder", the Nextcloud client will enforce read-only permissions of the root share ("Documents"), rather than the read-write permissions of "somefolder". In order for UserB to write to "somefolder", it must be accessed via "\~/Nextcloud/Shared/somefolder".

It seems that the Nextcloud client should enforce correct permissions of "somefolder" regardless of the path used to access it, which would match the behavior seen when accessing shares from the web client.

### Steps to reproduce

1. Create a share with read-only access to another user
2. Create a new share in a subfolder of the share from step 1 with read-write access to the same folder
3. Access the share using the absolute path locally.
...

### Expected behavior

One would expect permissions of nested shares to always be consistent, regardless of the path used to access them.

### Which files are affected by this bug

unknown

### Operating system

Linux

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

Gentoo

### Package

Official Windows MSI

### Nextcloud Server version

29.0.7

### Nextcloud Desktop Client version

3.11.1

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

Updated from a minor version (ex. 3.4.2 to 3.4.4)

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

Encryption is Disabled

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

- [X] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

_No response_

### Additional info

_No response_