fix(thumbnails): regenerate external photos, and stop destroying good ones (#1129)

POST /admin/thumbnails/regenerate resolved every source as
storage/events/active/<photo.path> and fs.access'd it. External and reference
rows are not there — their originals live under events.external_path — so every
one failed the check and was counted as an error, while the UI reported success
because the response is sent before the background loop starts.

It now goes through ensureThumbnail, which resolves both source kinds and writes
thumbnail_path back itself. Nulling thumbnail_path stops it short-circuiting on
isThumbnailValid, which matters because the old thumbnail is normally still
readable at exactly the moment someone presses regenerate.

And the half that destroys data: generateThumbnail deleted the target BEFORE
sharp had opened the source, and again in its catch. A source that could not be
read — a NAS mount that blipped — left the previous rendition gone and the
database pointing at it. Across a bulk regenerate that is the whole gallery.
Neither delete was needed: put stages to a temp file and renames atomically, and
put is the last statement in the try so no partial object can exist.

Also: videos filtered out, and the superseded rendition removed only when the
storage key actually moved, compared through the same canonicalisation the
backends apply.

Stable twin of #1134.

backend/src/services/imageProcessor.js

@@ -133,10 +133,18 @@ async function generateThumbnail(imagePath, options = {}) {
   // Get thumbnail settings
   const settings = await getThumbnailSettings();
 
-  // Force regeneration: drop the existing object before writing the new one
-  if (options.regenerate) {
-    await storage.delete(thumbnailRelKey).catch(() => {});
-  }
+  // `options.regenerate` deliberately does NOT delete the existing object first
+  // (#1129).
+  //
+  // It used to, and the delete ran BEFORE sharp had even opened the source — so
+  // a source that could not be read (a NAS mount that blipped, a corrupt file)
+  // left the old thumbnail already gone and returned null, with the database
+  // still pointing at it. One bulk regeneration during a mount outage could
+  // therefore strip every canonical thumbnail in a reference gallery.
+  //
+  // Nothing is lost by dropping it: LocalFsStorage.put stages to a temp file and
+  // renames over the target, which replaces atomically, and an S3 put overwrites
+  // by key. The delete only added a window with no thumbnail at all.
 
   try {
     // First, verify the source image is complete and valid
@@ -192,9 +200,12 @@ async function generateThumbnail(imagePath, options = {}) {
     const msg = (error && error.message) ? error.message : String(error);
     logger.error(`Failed to generate thumbnail for ${sourceBasename}: ${msg}`);
 
-    // Clean up any partially uploaded object
-    await storage.delete(thumbnailRelKey).catch(() => {});
-
+    // No cleanup delete here either, for the same reason (#1129). This was
+    // "clean up any partially uploaded object", but there cannot be one:
+    // storage.put is the LAST statement in the try, every throw above it
+    // happens before anything is written, and put unlinks its own temp file on
+    // failure. The only object this could remove is the PREVIOUS, valid
+    // rendition — exactly the thumbnail a failed regeneration must leave alone.
     return null;
   }
 }