Important edit: Since I’ve marked this as the solution, I’ve discovered that CIFS with cache=none is extremely slow. I noticed my backups were taking longer than normal. I ran a dd test with one of my shares mounted via NFS and then the same test with CIFS (with cache=none):
NFS: (14.3MB/s - not great, but OK):
root@home:/media/duplicati_a# dd if=/mnt/nas/Backup/home-backup.tar.gz of=/media/duplicati_a/testfile status=progress
816660992 bytes (817 MB, 779 MiB) copied, 57.0038 s, 14.3 MB/s
I do believe this is the solution - mono has problems with CIFS caching. Thank you @JonMikelV for your help and for suggesting that mono might be having trouble with CIFS shares.
CIFS: (84.4kB/s) 
yes that’s a “k”; I didn’t bother letting it finish.
root@home:/media/duplicati_a# dd if=/mnt/nas/Backup/home-backup.tar.gz of=/media/duplicati_a/testfile status=progress
22611968 bytes (23 MB, 22 MiB) copied, 268 s, 84.4 kB/s
Final answer: use NFS.
I mounted the same share on my NAS on two different mount points, with one mount point using cache=none, and the other mount point using the default cache=strict as verified with the mount command.
Then I restored the same ~4GB dataset to two different directories in this mount, using one mount point for each restore:
Restore to r-cifs/nocache, total size:
3.90 GB (4,195,885,480 bytes)
Restore to r-cifs/strictcache, total size:
3.83 GB (4,114,604,523 bytes)
Perhaps more interesting is the Duplicati has no idea anything went wrong. No errors in the second restore report, but WinMerge reports 7 files are truncated in the /strictcache version.
The solution here is to turn off caching for CIFS mounts. My corrected /etc/fstab line contains:
rsize=32768,wsize=32768,cache=none
I’ll run more tests in the coming days but I’m fairly confident in this result based on what I’ve seen elsewhere about mono and CIFS caching.