[Feature Request] Add a per-run upload data limit (--max-upload-per-run)

There is no way to limit the total amount of data uploaded to the backend during a single backup run. Users who back up to cloud providers with daily or monthly transfer caps have no mechanism to prevent a single run from exhausting their quota. Many popular storage backends impose hard per-day or per-month transfer quotas that are independent of storage capacity.

When a Duplicati run exceeds these limits, the backend rejects further uploads. The user is left with an incomplete backup, a failed run, and no way to control the damage. Currently, the only workarounds are OS-level QoS policies or the --throttle-upload option, which limit speed but not total volume.

Proposed solution is to add a new option: --max-upload-per-run=SIZE

When the cumulative bytes uploaded during the current run reach this threshold, Duplicati should:

• Stop uploading further volumes (let in-flight uploads finish).
• Mark the run as "partial" in the log and UI, with a clear warning.
• Queue the remaining volumes to resume on the next scheduled run (the next day, week, or month).

This is distinct from: --throttle-upload — limits bandwidth, not total volume. --quota-size / --quota-warning-threshold — warns about total backend storage used, not per-run upload volume. --asynchronous-upload-limit — limits concurrent streams, not total data.

I understand that the deduplication architecture makes it hard to predict the final size before a run completes, but it does not prevent checking a running counter during the run. Each volume upload is a discrete, measurable operation. Checking bytes_uploaded_this_run >= threshold before starting the next volume upload is straightforward and does not require knowing the final total.

The concern raised in the forum discussion (cancelling mid-run leaves an incomplete backup) is valid — but the solution is to not commit the partial state and clearly communicate the result, rather than to refuse the feature entirely. The current alternative—the completely failed run because the backend reached the daily upload limit—is worse.