The bland logs are themselves a data point. If the journal just stops mid-line with nothing unusual before it, that points at a hard hang or a power cut rather than something userspace did, because a kernel oops normally leaves a trace behind. There's also a catch-22 in the SD theory: a card that's failing can't reliably write the log that would prove it's failing.
Two things worth doing before the card swap, both cheap. Check vcgencmd get_throttled: bit 16 stays set if undervoltage happened at any point since boot, so you get an answer on power-versus-card without having to catch the crash live. And switch on the hardware watchdog, bcm2835_wdt plus RuntimeWatchdogSec in systemd, so the Pi resets itself instead of waiting for someone to pull the plug. That doesn't fix the cause, but it stops every crash from becoming an outage that lasts until you're back home.
Before you redo the rest by hand, check whether the broken ones share a format. Black frames that render fine on the phones but not in a desktop browser usually mean the original file is intact and it was the server-side preview that failed to generate, with the phones quietly decoding the original themselves. HEIC and HEVC and 10-bit HDR are the usual suspects, since those lean on libheif and ffmpeg on the server and older builds choke on them.
If that's the cause, re-uploading only "works" because it reruns preview generation, so you're really just triggering a fresh encode. Grep the museum logs around one of the bad files for a decode error, and see whether a rescan or clearing the thumbnail cache regenerates them in place. That would save you doing the whole library one file at a time.