Incidentally, the file seems to have uploaded to Phabricator just fine!

It magically works now. You can close this if you'd like. Though it's worth looking into what causes a file to be rejected and subsequently accepted.

I tried to "stress test" the system and managed to get 114 uploads in before it started throwing the error message.

Note that the "this file might be corrupt" error can occur at any point in the process. Even if the upload succeeds on the initial upload screen it might still throw that error on the finalization screen.

Well, I uploaded around 1000 PDF files with UploadWizard to Commons in the last few hours and not a single of them failed. Perhaps this only kicks in if you publish some of the uploads, which I didn't do (only uploaded to stash).

The API call can return some more details than UploadWizard displays, but we don't log it anywhere (T130485). I'll try to look into that. Or maybe upload some PDFs to testwiki.

I found out that there is a throttle, sneakily implemented as an AbuseFilter filter (filter 140, which you indeed hit many times). UploadWizard is not very smart about reporting actions blocked by filters (T132866), and due to T87381 every UW upload counts towards the limit twice (once when uploading, and once when publishing the file description).

Non-autopatrolled users can upload at most 380 files per 4320 seconds (72 minutes). You should probably request that user right at Commons if you're planning any more big uploads (the error message that UW should be showing you, but doesn't, says so: https://commons.wikimedia.org/wiki/MediaWiki:Abusefilter-warning-ut). I have patroller rights on Commons and so didn't hit this when testing myself :/

I filed T132930 and T132920 about converting the filter to site configuration and making UploadWizard understand rate limits (with filters, even I make it display the message, it still won't know to stop uploading when it hits this error – and I think every failed upload attempt also counts towards the limit).