I would personally say that this is something you can trivially script if you want to. Plus the requirement for server B to have the backup sets data encryption keys makes this moot. That’s something which is totally unacceptable from security standpoint.
It’s just better to run the backup of the backup, without decrypting the data. Sure you’ll end up also having the “stale” data in the blocks in the final backup, but so what. It’s a small price to pay for the extra security of having backup version of the backup, in the unlikely (?) situation where ransomware or APT attacker is able to detect Duplicati running and decides to destroy / corrupt / encrypt the Duplicati’s backup storage.
Another way of achieving something like this was the method I’ve asked a long time ago, where you could run separate compact process (without database), which would allow configuring the backend so that the actual backup clients have create / write access only, without possibility to modify / delete existing data and preventing sabotaging the existing backup sets using that access path.