fix(files/cache): uniqueness guarantees in the file cache layer

[solracsf]

Summary

Replaces row-by-row PHP aggregation with a single SQL query using five aggregates an thus eliminating a second round-trip to the database that was a performance regression for encrypted storage.

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

[provokateurin]

Fixes a bug where all rows in a batch shared the same etag (it was computed once at query-build time and reused). Each entry now gets a unique cryptographic etag, preventing stale cache responses in WebDAV clients.

I don't understand what the problem was and why it needed to be fixed. Multiple rows having the same etag is completely fine. The only important thing about the etag is that it changes, not that it's unique.

[solracsf]

Yep, the "uniqueness guarantee" framing suggests a bug that didn't exist...
I'll revert the uniqid() usage and keep only performance improvements on SQL queries.