Fix/57375 zero quota external storage folder delete

[huntervcx]

• Resolves: [Bug]: Users With 0B Quota Cannot Delete Folders In External Storage #57375

Summary

Users with quota set to 0 (intentionally, so nothing is stored under their home files/ except structure / external mounts) hit incorrect WebDAV failures:

1. MKCOL / uploads / moves could fail with 507 Insufficient Storage because QuotaPlugin treated directory creation like a fixed byte write (4096) against free_space == 0, and the home Quota wrapper blocked mkdir when quota was exhausted.

2. With files_trashbin enabled, DELETE on items on external storage could return 403 Forbidden (Directory::delete → rmdir false) because Quota::copyFromStorage / related write paths did not honor shouldApplyQuota() — writes under files_trashbin/ were incorrectly subject to the same free_space == 0 gate as real user files under files/.

This PR aligns quota enforcement with the existing intent of shouldApplyQuota() (only paths under files/ count toward user quota):

• QuotaPlugin: skip pre-quota checks for directory creation (MKCOL); empty dirs do not consume user quota bytes.
• Quota wrapper: allow mkdir when quota is exactly 0 for empty directories; delegate real file blocking to fopen / file_put_contents / etc.
• Quota wrapper: apply shouldApplyQuota() to copyFromStorage, moveFromStorage, copy, file_put_contents, and touch so trashbin / versions / metadata paths are not blocked when home quota is 0.

Unit tests updated in tests/lib/Files/Storage/Wrapper/QuotaTest.php and apps/dav/tests/unit/Connector/Sabre/QuotaPluginTest.php.

TODO

• CI green

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[huntervcx]

Behavior Matrix After Full Fix

Scenario (quota = 0)	Before	After
MKCOL in home / SMB	507 / 403	OK (fix 1)
PUT in files/	507	507 (correct)
PUT in external SMB	OK	OK
DELETE → trashbin (copyFromStorage)	403 Forbidden	204 No Content
Versions (files_versions)	blocked	OK
Touch in files/	blocked	blocked (correct)
Touch elsewhere	blocked	OK

I'm still not entirely certain whether the behavior for trashbin and versions is fully aligned with the intended design.

That said, with this fix, it is now possible to create directories in the user's home even when the quota is set to 0. From Nextcloud’s perspective, this is technically consistent, as empty directories do not consume any storage (0 bytes), and therefore do not violate the quota constraint.