fix(preview): regenerate previews whose stored file is gone

[rayvincent2]

• Resolves: [Bug]: Preview generation fails when DB entry exists, but local file does not #63349

Summary

If a preview database row exists but the stored file is gone, generation used that row and then failed when it tried to read the file. Generator now checks that the file is still present, deletes the stale row if it is not, and regenerates the preview. That covers a missing max preview and missing extra sizes when several sizes are configured for one file.

Unit tests cover local storage, object storage, and multiple sizes per file.

Live test: I applied this change on a Nextcloud 34.0.3 instance with local preview storage. occ preview:generate had been failing with NotFoundException from LocalPreviewStorage::readPreview (DB row for 1535-2048-max.jpg, file missing). After the change the same command succeeded. Several other images were in the same state. Opening them in Memories requested previews again and those thumbnails regenerated instead of staying broken.

I have not live-tested object store or a full preview:generate-all re-run.

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 (not a front-end change)
• 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

I used Grok to implement the fix and tests; I reviewed the diff, ran the unit tests, and verified it on 34.0.3.

[rayvincent2]

Follow-up to the live-test note in the description: I have now run a path-scoped preview:generate-all on production (34.0.3 + this patch, local preview storage).

Context: I had already completed successful preview:generate-all runs over all images earlier (including repairs of missing preview files via this change). The runs below are not a cold full regenerate of missing previews — they are re-runs over a tree where previews already exist. “Cold” vs “warm” here only means first pass vs second/third pass with OS page/dentry cache for stat (and similar) warmed.

docker exec -u www-data -e PHP_MEMORY_LIMIT=2G nextcloud-manual_install-nextcloud \
  php -d memory_limit=2G /var/www/html/occ preview:generate-all -vv \
  --path "/ray/files/Photos/My Photos/2026"

Results for /ray/files/Photos/My Photos/2026:

• 1050 source files (find ray/files/Photos/My\ Photos/2026: -type f | wc -l)
• Verbose log showed 1050 Generating previews for each run
• First pass (cold) finished in ~17s (real 0m17.622s)
• Second pass (warm) finished in ~3s (real 0m3.097s)
• Third pass (warm) finished in ~3s (real 0m3.194s)

So this is a smoke / regression check that preview:generate-all still walks the tree cleanly with the patch applied when previews are already present. The original bug (DB row present, preview file missing → hard fail on readPreview) was verified earlier with single-file preview:generate on known-broken rows.

I still have not live-tested object-store primary storage.

[CarlSchwan]

this generates network requests, which is not great for performance. I wonder if for object store we could just always return true (at least for now until a better solution is found)