[Bug]: Version 33.0.0 and Cookbook app causing memory leak on desktop client. #9685

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Having the cookbook extension enabled on a Nextcloud server which is having files synced via the Desktop Client causes the Desktop Client to leak memory.
It also causes consistent CPU usage (~4% on a Ryzen 7 5800X, plus additional usage from Windows Defender scanning the created log files) , disk usage (~1.5MB/s, presumably writing to logs), and network usage (~120KB/s)
See image for resource usage with this bug. Note, the memory usage continues to increase (I've seen it as high as 7GB)

Steps to reproduce

1. Enable Cookbook on a Nextcloud server
2. Ensure a folder is being synced via the Desktop Client
3. Switch from "No proxy" to "Use system proxy" (without this, it may not work from just installing the app, this seems to refresh something)
4. Wait for memory usage to slowly increase.

Expected behavior

No memory leak, this app doesn't sync anything to desktop anyways.
See image for usual Desktop Client resource usage

Which files are affected by this bug

gui\creds\webflowcredentials.cpp, src\libsync\accessmanager.cpp

Operating system

Windows

Which version of the operating system you are running.

Windows 10

Package

Official Windows MSI

Nextcloud Server version

32.0.6

Nextcloud Desktop Client version

33.0.0

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

Updated to a major version (ex. 3.16.3 to 3.17.0)

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

There are no server logs from around the time that this bug occurs.

Additional info

Switching from "No proxy" to "Use system proxy" (or vice verca) clears the memory used,
I've only attached a portion of the desktop logs, as it is the same thing for over 39k lines, over the span of 4 minutes.

log_upload.log