The first problem is the conflation of the two modes in one button. The UI leads users to think that Repair works on the local database. Repairing the local database and deleting remote data are very, very different things!
One usually winds up doing these sorts of things because something has gone wrong. Typically a user is anxious, upset… though this is a time that reading documentation, searching forums and double-checking everything should prevail, in practice it doesn’t always work out that way. (My experience here.)
In my opinion that’s a primary need. Make the user interface clear, so users know they will be deleting files from remote storage (and can choose to back up the backup first, if appropriate).
Once that’s done: If files can’t be moved on the remote, can they at least be renamed (to something Duplicati will “know” should be ignored), and only deleted as a second, separate step once success of the repair operation has been confirmed? If that is impossible too, what about creating dummy “flag” files with the same name and a different extension to tell Duplicati which files are to be ignored?