Upload queue does not respect updated duplicate-handling settings.

> Yep, Same frustration here.
>
> What configuration do you use for the upload?
>
> I had "move to app folder" which is unfortunately a must in order to have some safety on which pictures are actually uploaded and "always ask on duplicates".
>
> That combination caused all the troubles described here. Pictures not uploaded, tons of pictures in the queue waiting for upload although they were not existing anymore in the original folder because they were moved already by the app to the app folder etc.
>
> Switching to "rename duplicates" made it worse an created hundreds of duplicates on the server but not stopping to try to upload again and again.
>
> Since I switched to "move to app folder" and "skip duplicates", all photos are uploaded and moved. So maybe this hints towards the cause of others can confirm this.
>
> Unfortunately it seems that one has to wipe the app in order to change these settings because those pictures in the queue seem to be handled according to whatever config you had before.
>
> Loosely related to this topic. Can you think of a situation where it makes sense for the upload to replace a >0 byte file with a 0 byte file?
>
> Imho in that situation the app should always ask, even if skip or replace is configured because almost always replacing a file with a 0 byte version is wrong.

_Originally posted by @svenb1234 in [#16550](https://github.com/nextcloud/android/issues/16550#issuecomment-5077364561)_

Start by tracing the Android upload queue and how it reads duplicate-handling settings for items already queued. Reproduce the reported configuration change with queued photos, including the zero-byte case; done means queued uploads follow the current setting and do not incorrectly retry or replace files.

Written by the indexing model from the issue text.