[Bug]: client unusable on Arch, tried multiple versions

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

Multiple issues; in principle they should be reported separately but I am moving on from Nextcloud as I need reliable data storage today.

Two systems, both running Arch Linux, hardware differs (laptop vs desktop) but identically configured otherwise, both updated fully at least once a day. If you're not familiar, Arch uses rolling releases and there isn't really a "current version" to give of the OS. Basically, though, more current than any other distro you're likely to use, so generic "maybe you're not using the updated thisorthat library" answers will not help.

1. One machine has ~280GB in ~168,000 files; all drives are local. On this, sync never happens at all. The client reports scanning something like 36K files and 116GB, then CPU utilization goes to zero and nothing further happens, even if left alone overnight. I've removed and re-added the sync folder multiple times, deleted hidden Nextcloud files within it each time, removed everything in .config/Nextcloud and .local/share/Nextcloud multiple times. I've tried the AUR current version, 3.15.3daily, as well as the 15.3 and the 14.3 AppImage versions. No change to behavior of the app. .nextcloudsync.log always has zero bytes. (I also renamed files with names that were "too long"...)
2. Second machine has ~55GB in ~82000 files, a subset of the same files on the larger machine. Sync works fine. At some point after starting, time involved varied and I didn't track it, one core goes to 100% utilization. I've only tried the Arch version of Nextcloud on this machine (though I've uninstalled and reinstalled and deleted local files as described above several times), as if the machine above doesn't work at all there's no point in addressing this on my end. There are always 0 bytes in .nextcloudsync.log on this machine as well. As a minor side note, it's fairly ridiculous to fail to sync some files because of long filenames. I figured out an easy workaround bc those particular files are only accessed by an app I wrote, but still. This issue affected nothing else in this "report," as the other issues existed with or without those files.

I hope you guys fix this stuff for other users, but it seems unlikely to be done soon. So I've uninstalled the Nextcloud client and moved on to a simple rsync/inotifywait solution for now. I am willing to reinstall and play with it a bit if you need more info, but that's about the limit of my future involvement.
...

### Steps to reproduce

1. Start Nextcloud
2. Log in if necessary
3. Watch the issues above happen.

### Expected behavior

Syncing would have been nice to see. Also, eternally using 100% of a core and locking up the client should probably not happen. Quite possibly the sync log file should either have content or not exist if it's unused. Given that all systems involved are running Linux, and all files are accessible locally, the "long filename" issue likely should not exist.

### Which files are affected by this bug

.nextcloudsync.log

### Operating system

Linux

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

Arch Linux (doesn't have versions as it's a rolling release)

### Package

Official Linux AppImage

### Nextcloud Server version

hosted with hetzner

### Nextcloud Desktop Client version

15.3.3daily, 15.3 AppImage, 14.3 AppImage

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

Fresh desktop client install

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

Encryption is Disabled

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

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

### Nextcloud Server logs

```shell
not available
```

### Additional info

I am not able to send you logs, as they include confidential info (filenames, at least for the unencrypted files).