fix(core): handle parameter limits in files metadata deletion

[gitedmond]

• Resolves: [Bug]: files:scan creates oversized files_metadata DELETE query and causes severe resource usage #62325

Summary

dropMetadataForFiles() was already intended to split file IDs into chunks using IQueryBuilder::MAX_IN_PARAMETERS, but the DELETE query mistakenly bound the original $fileIds array instead of the current $chunk. As a result, every query still contained the full ID list and could exceed database parameter limits.

This PR passes $chunk to each query and adds regression coverage that verifies the exact chunks sent to the query builder.

Testing

Added a regression test using more than two parameter-limit batches. It verifies that every ID is bound exactly once, in order, and no query receives more than MAX_IN_PARAMETERS IDs.

AI (if applicable)

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

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[come-nc]

Hello,

Please switch back to using the const MAX_IN_PARAMETERS, we do not want to have a magic number 500 in there.

Nice catch on the wrong var being used.

Regarding the transaction I lack knowledge to judge in it makes sense here. Is a partial metadata deletion an issue?

[gitedmond]

Hello,

Please switch back to using the const MAX_IN_PARAMETERS, we do not want to have a magic number 500 in there.

Nice catch on the wrong var being used.

Regarding the transaction I lack knowledge to judge in it makes sense here. Is a partial metadata deletion an issue?

You're right: the transaction is not needed for this fix, and it would not make metadata and index deletion atomic because those happen in separate calls. I've removed it. The PR now only binds each existing MAX_IN_PARAMETERS chunk instead of the full $fileIds array, with a regression test that verifies the exact chunks passed to the query builder.