Trashbin move can OOM due to full folder size recalculation

Description

WebDAV DELETE can hit PHP memory limit during trashbin move, leaving request aborted. The memory spike appears tied to folder size recalculation in cache updates during Trashbin::move2trash().

This surfaces in Ticket#9687404: deleting a tiny file via WebDAV consumed >500MB and the request died. The trash payload exists, but metadata/cache may be inconsistent. Related to #56493, but the root cause here is the memory‑OOM path, not just non‑atomic metadata ordering.

Steps to reproduce (likely)

1. Use a user with a very large folder (many children) in home storage.
2. Delete a file from that folder via WebDAV/UI (trashbin enabled).
3. Observe PHP memory growth during Trashbin::move2trash().

Actual result

• WebDAV DELETE hits memory limit (PHP fatal), request aborts.
• Inconsistent trash state possible: payload moved but DB/cache incomplete.

Expected result

• Trash move should not require full folder scan or excessive memory.
• Delete should be robust even on large folders.

Analysis / suspected root cause

During trash move, cache updater calls renameFromStorage() which triggers Cache::correctFolderSize() for source and target. That calls calculateFolderSizeInner() and fetchAll() on child entries (large folders) which can blow memory.

Relevant paths:

• apps/files_trashbin/lib/Trashbin.php → move2trash() → Updater::renameFromStorage() / update()
• lib/private/Files/Cache/Updater.php → copyOrRenameFromStorage() → Cache::correctFolderSize()
• lib/private/Files/Cache/Cache.php → calculateFolderSizeInner() (fetchAll())

Proposed direction

• Add a fast path for trash moves to avoid full folder size recalculation; use known size delta to update parent sizes, or defer size correction to background.
• Alternatively: add optional size‑delta parameter to renameFromStorage() and skip correctFolderSize() when provided.

Notes

PR #57360 mitigates orphaned metadata by inserting files_trash row before payload move, but does not fix memory‑OOM path.