Solved: [Bug]: Can't sync some files with the desktop client (Linux/Archlinux); v 3.15.3 → Feature Request: The Client should check soft limits

### ⚠️ 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

Today I discovered that some files weren't synchronized. I can't say for sure if this problem was introduced with the latest client, version 3.15.3, or before. I tried various measure to solve this problem, but all of them failed. I then deleted the sync journal and tried again. The problem persists

### Steps to reproduce

I the problem reoccurs on the production system, but I can't reproduce it on a test installation.

The log file says:

```
2025-03-06 17:35:08:052 [ info nextcloud.sync.discovery /usr/src/debug/nextcloud-client/nextcloud-client/src/libsync/discovery.cpp:553 ]: "Processing \"B*.pdf\" | (db/local/remote) | valid: false/true/false | mtime: 0/1741276452/0 | size: 0/3090179/0 | etag: \"\"//\"\" | checksum: \"\"//\"\" | perm: \"\"//\"\" | fileid: \"\"//\"\" | type: CSyncEnums::ItemTypeSkip/CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeFile | e2ee: false/false | e2eeMangledName: \"\"/\"\" | file lock: not locked// | file lock type: \"\"//\"\" | live photo: false//false | metadata missing: /false/"
2025-03-06 17:35:08:052 [ debug nextcloud.sync.discovery /usr/src/debug/nextcloud-client/nextcloud-client/src/libsync/discovery.cpp:1046 ] [ OCC::ProcessDirectoryJob::processFileAnalyzeLocalInfo ]: File "B*.pdf" - servermodified: false noServerEntry: true
2025-03-06 17:35:08:052 [ info nextcloud.sync.discovery /usr/src/debug/nextcloud-client/nextcloud-client/src/libsync/discovery.cpp:1347 ]: Not a move, no item in db with inode 3719329
2025-03-06 17:35:08:052 [ info nextcloud.sync.discovery /usr/src/debug/nextcloud-client/nextcloud-client/src/libsync/discovery.cpp:1700 ]: discovered "B*.pdf" CSyncEnums::CSYNC_INSTRUCTION_NEW OCC::SyncFileItem::Up CSyncEnums::ItemTypeFile
```
I redacted the file name because it included the name of applicants.

### Expected behavior

The files that weren't syncronized should be syncronized.

### Which files are affected by this bug

B*.pdf

### Operating system

Linux

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

Arch Linux

### Package

Distro package manager

### Nextcloud Server version

Nextcloud Hub 9 (30.0.6)

### Nextcloud Desktop Client version

3.15.3

### 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

```shell
Can't access them. The server is not managed by me.
```

### Additional info

_No response_

Start by reviewing the discovery paths referenced in src/libsync/discovery.cpp at lines 553, 1046, 1347, and 1700, then inspect how the desktop client handles the affected B*.pdf entry. The issue does not define the soft limits to check or identify tests; done would require an agreed behavior and verification that files exceeding those limits are handled as intended.

Written by the indexing model from the issue text.