Large file uploads to a chat do not survive screen-off, Doze or network loss #6826

Is your feature request related to a problem? Please describe.
When I send a large file (a video, for example) to a chat and the screen turns off, the device enters Doze or the network drops, the upload stops and often ends as "failed". Reading the code at f3c9097, I see these causes:

• The worker runs without setForeground, so the system is free to stop it when the screen is off (UploadAndShareFilesWorker.kt#L558-L564).
• Every IOException uses one of MAX_UPLOAD_ATTEMPTS = 4, and a stop by constraints counts too; after that the upload gives up (#L212-L222, #L482).
• onStopped() calls abortUpload() on any stop, which deletes the chunks already on the server (#L427-L434, ChunkedFileUploader.kt#L338-L354).
• The PROPFIND for existing chunks requests no properties, so resourcetype is never parsed and isFile stays false: resume never finds a chunk (#L132-L134, #L169).
• With compression on, every attempt compresses the file again (#L166-L168), and the chunk folder is the md5 of that file (#L71). A new copy can give a new folder, so earlier chunks are lost.

The open PR #6805 makes a network error reach the existing retry path. It does not address the points above. Users report the symptom in #4115.

Describe the solution you'd like

1. Resume: request resourcetype and size in the PROPFIND, upload only the missing chunks into the same folder, and keep the chunks when the work is stopped by the system or by the network. Only an explicit cancel deletes them.
2. Prepare once: copy and compress the file once per upload and reuse the result, so the folder key stays stable across attempts.
3. Foreground work: run the upload as a foreground dataSync work with a progress notification and a Cancel action.
4. Retry policy: network errors (including TLS drops), 5xx except 507, 408 and 429 retry without a limit and wait for the network. The limit of 4 attempts stays for server refusals (other 4xx, 507, certificate errors).

Describe alternatives you've considered
Keeping the current limit and only extending it. A long upload on a mobile network would still lose its chunks on each stop, so it does not solve the problem.

Additional context
I have an implementation ready in my fork. I propose to send it as two PRs: #6827 (resume and error handling in ChunkedFileUploader, prepare once) and #6828 (foreground work and retry policy). It builds on #6825 (a crash in abortUpload() when the worker is stopped). #6827 covers the change of #6805 (it rethrows network and HTTP errors from upload()), so #6805 can be closed if #6827 is accepted; if #6805 is merged first, I will rebase #6827.
Tested by the author on a Huawei DEL-LX9 with a fork build.

Questions to maintainers:

• Is this direction acceptable, and is the split into two PRs fine for review?
• Is a foreground dataSync service (with the FOREGROUND_SERVICE_DATA_SYNC permission) acceptable for this app?
• Should this wait for Migrate workers to coroutine workers #6770 (worker migration to CoroutineWorker), which also touches onStopped()?

The analysis and this text were prepared with an AI assistant and reviewed by me.