I have no idea, if the files were really moved source files would be deleted, if it was a specific fodler/share you can run rsync with --remove-source-files so any existing files on dest will be skipped but source files that already exist on dest will still be deleted from source.
That's not uncommon with SSDs, they fail after a power off, and they fail much less than disks but when they fail they usually fail completely, no way that I know of recovering data other than using professional data recovery services.
That's usually a USB thing, though some controllers/bridges work better than others.
They look like a connection issue, usually it's a bad SATA cable, replacing them should help.
This means that filesystem is already mounted, likely the USB device dropped offline without a clean unmount, rebooting the server should fix it, if it doesn't post the output of:
blkid
after rebooting.
It counts as an overclock every time it's above AMD's max officially supported speeds, and it's a known source of data corruption with Ryzen.
No because usually both copies are corrupted, if it could be a scrub would repair it, this means it can't:
Other than that I'm not seeing anything out of the ordinary, can you try without the Nvidia driver? One of just two google results I found about that error mentioned an issue with that.
If you're removing parity do it before adding the new drives, or they will be cleared before they can be used.
Before starting the array check "parity is already valid" or it will be resynced, you can still run a check after to confirm all is well.