trash_bin_collect causes extreme memory usage / OOM on large recycle-bin directory tree

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed. / 请使用英语提交，否则会被关闭。
• Please do not modify this template :) and fill in all the required fields.

Cloudreve version

4.19.0 Pro, commit 26ad1c53

Pro or Community Edition

Pro

Database type

PostgreSQL

Browser and operating system

Firefox 155 on Windows 10; Cloudreve runs in Docker on Unraid 7.3.2 (kernel 6.18.38-Unraid).

Steps to reproduce

1. Run Cloudreve Pro 4.19.0 with PostgreSQL and local storage.
2. Put a very large directory tree in the recycle bin. My test directory contained:
   • 140,313 total file/folder records including the root
   • 137,682 files/entities
   • about 2,630 directories
   • maximum depth 7
   • about 7.2 GB of data
3. Let the recycle-bin retention period expire and allow trash_bin_collect to run, or use "Empty Recycle Bin".
4. When Cloudreve starts processing this directory tree, memory usage rapidly increases until it reaches the Docker memory limit.
5. The issue reproduced with both a 4 GiB and an 8 GiB memory limit.

✔️ Expected Behavior

Large recycle-bin directory trees should be deleted incrementally or in batches, with bounded memory usage. The cleanup may take a long time, but it should not consume all available container memory or cause an OOM kill.

❌ Actual Behavior

When trash_bin_collect processed the large directory tree, Cloudreve rapidly increased from a few hundred MiB of RAM to the configured memory limit.

With a 4 GiB Docker limit, Cloudreve reached ~4 GiB and was killed by the memory cgroup OOM killer.

With an 8 GiB limit, manually using "Empty Recycle Bin" caused the same behavior:

• ~7.999 GiB / 8 GiB RAM
• ~1300% CPU
• very high disk I/O
• the operation did not complete before I stopped the container

The issue was reproducible when this large recycle-bin directory was processed. After manually removing that directory tree from PostgreSQL and local storage, Cloudreve returned to ~180–250 MiB RAM usage and remained stable.

Addition context information

Problematic item was a Syncthing .stversions directory on local storage; after manually removing its ~140k-node subtree, the issue disappeared.