I apologize, I misinterpreted "report back here" but I did not look at the distribution list or grab "reply all".
I prepared to follow the suggestions, although I was not going to risk that particular microSD unless it was clearly needed. As I prepared to dd to new a new SD, I realized that asking a desktop computer to copy many files was already taking us out the reasonable possibility of replicating the error, because that required (1) an external filesystem (2) thumbnails on and (3) letting Linux copy the files while the thumbnails are being updated. As I was writing the bug report, I tried turning thumbnails off and noted that was a workaround. As far as the bug itself, it looks like a race condition or maybe a buffer collision. One can literally watch the corruption in action. It is likely to succeed if there are only a few files to copy.
In order to validate the SD's size, I used dd to copy the raw image to /dev/null, reporting: 331914983424 bytes (32 GB, 30 GiB) copied, 815 s, 39.1 MB/s.This and the other SD I bought with it are on a well-known brand and I have used them extensively. I delete the offending files, rescan, give it to Windows or Linux without thumbnails on, and the files are intact. I can insert the SD into the laptop's slot and the same problem occurs. If I move the files (in a folder) through the network, or any manner other than on the SD's FAT32 filesystem, all is well.
As I wrote, the compressed raw image (starting on a new microSD) was still almost 500MB and I was unable to upload it.