If it was encrypted you could first try using either SharpAESCrypt.exe program shipped with Duplicati or the AES Crypt for Linux program. The integrity check sounds like it should be able to find any corruption. ZIP may vary. Duplicati.CommandLine.RecoveryTool.exe happily downloaded and unzipped a zip file that I’d corrupted, until I chopped a big chunk out of the middle, instead of just altering bytes – first at the end and then various. The 7-Zip Test caught even the first one. perhaps ZIP programs have both permissive and pedantic modes? You could, if you like, repeat my test to see how sensitive your test is. If good, you could try the “move aside” (and move it far enough aside that Duplicati cannot even see it – preferably move it totally out of that folder).
If the hash problem was a random old file being tested, it could come up again. Too bad you can’t see it now to see if it’s like the file unzip -t found. I’m uncertain about Unexpected difference in fileset future.
–full-remote-verification isn’t documented to say it runs any further, but simply looks deeper into sample files. Documentation can be wrong, and I haven’t looked at code. Still, I wonder if the word “full” is a bit misleading, like “repair” and “list-broken-files” mean in a limited way. See earlier lament about capabilities and limitations.