Refactor: Unified Auto Upload Architecture

[PhilippThaler]

Built upon #56 and based on #124
So there aren't that many changes if #56 is merged first

Summary

This PR is mostly about refactoring the background workers to use a unified upload architecture. Instead of having "Picture" and "Video" logic hardcoded everywhere, the background sync is now entirely driven by the configuration itself.
This gives us a much cleaner foundation so we can eventually support custom folders and other features for auto uploading in the future.
While creating this, I also fixed a few edge cases, I ran into where settings would overwrite each other, or where files would end up in the wrong folder if you changed your settings while waiting for Wi-Fi.

What changed

• Unified the upload logic: The workers no longer care if a file is a picture or a video. They just look up the configuration and do what it says.
• Moved the subfolder logic: I moved the buildUploadPath function from Feature: Add Subfolder Strategy for Automatic Uploads #56 into a shared helper (AutoUploadPathBuilder) so both the scanner and the actual upload worker can use it.
• Calculate paths at the very last second: Before, the app locked in the upload path as soon as it found a new file. Now, it calculates the final path right before it hits the network. This means if a file is waiting for Wi-Fi and you change your destination folder in the settings, it will actually go to the new folder.
• Fixed settings getting overwritten: The worker now fetches the latest settings right before saving its sync timestamp. This stops it from accidentally restoring old settings if you changed them while the worker was running.
• Fixed picture/video mixups: Because we moved to a unified config system, I added a strict check on the config name. This stops the app from mixing up picture and video settings if they are both watching the exact same local folder (like /DCIM/Camera).

How to test

1. Normal uploads still work (Regression)
   • Turn on auto-uploads with subfolders, take a pic/video, and make sure it still works exactly like it did in Feature: Add Subfolder Strategy for Automatic Uploads #56. The unified logic shouldn't break anything.
2. Changing settings mid-upload
   • Turn on auto-uploads (Wi-Fi only) and turn off your Wi-Fi.
   • Take a picture/video so it gets queued up.
   • Go into the app settings and change the destination folder.
   • Turn Wi-Fi back on.
   • Verify: It should upload to the new folder, and the Uploads tab should update to show the new folder right as it starts.
3. Picture/Video mixup fix
   • Set up both Picture and Video auto-uploads for the exact same local folder (e.g., /DCIM/Camera) but with different target folders on the server.
   • Trigger an auto-upload.
   • Verify: The picture and video configs should stay completely separate and not overwrite each other in the database anymore.

So this

[zerox80]

Could u squash those commits?

[zerox80]

please solve this issues, then squash into 1 commit.

[zerox80]

Is it rebased now?

[PhilippThaler]

Squashed the current branch into 1 commit. The old branch has upstream merge commits in its history, so squashing it cleanly would be tricky — left it as-is for now. Happy to adjust if needed!

[zerox80]

What matters here is that the target folder can belong to a different Space, and the transfer needs to keep both the folder path and the spaceId.

1. Queued auto uploads can keep the old Space

For camera upload targets we store both remotePath and spaceId. The worker later resolves the WebDAV base from ocTransfer.spaceId, but when it refreshes the queued upload from latestConfig, it only updates remotePath.

A small fix would be to persist the refreshed spaceId together with the path:

ocTransfer = ocTransfer.copy(
    remotePath = uploadPath,
    spaceId = latestConfig.spaceId,
)

transferRepository.updateTransfer(ocTransfer)

Right now we only do this:

ocTransfer = ocTransfer.copy(remotePath = uploadPath)
transferRepository.updateTransferRemotePath(uploadIdInStorageManager, uploadPath)

So a queued upload can end up using the new folder path with the old Space WebDAV base.

2. Retrying failed auto uploads passes the wrong source

The retry path passes uploadToRetry.sourcePath as autoUploadSourcePath. For automatic uploads that value is the individual file content URI, while the worker matches configs by the watched tree URI. That lookup misses.

At minimum, retries should not pass the file URI as the auto-upload source:

val autoUploadSourcePath = when (uploadToRetry.createdBy) {
    UploadEnqueuedBy.ENQUEUED_AS_AUTOMATIC_UPLOAD_PICTURE,
    UploadEnqueuedBy.ENQUEUED_AS_AUTOMATIC_UPLOAD_VIDEO -> null
    else -> uploadToRetry.sourcePath
}

If we want retries to recalculate against the latest config, then the watched tree URI needs to be stored separately. Passing the individual file URI cannot work for that lookup.

[zerox80]

I think two things are still off here.

1. Light-user accounts should stay filtered out

The old picture and video screens excluded accounts with available == -4L, so light users could not enable auto upload in the first place. The unified picker now seems to build availableAccounts from every logged-in account, which brings those accounts back into the list.

That should probably stay filtered, something like:

availableAccounts = userQuotas
    .filter { it.available != -4L }
    .map { it.accountName }

2. Child preferences should be disabled while auto upload is off

Right now the sub settings stay active even when the main switch is off. That means changing Wi-Fi, charging, source, account, or behavior can still flow into composeAutoUploadsConfiguration(), which makes it possible to create or update a config just by tapping one of the child prefs.

The old screen blocked that by disabling the child preferences together with the main toggle, and I think that behavior still makes sense here.

[zerox80]

can u make sure that theres 1-2 commits instead 9 commits? i think u squashed but the old commits still appear