Add an expert-selectable Borg files cache mode per backup job

[TheTwist76]

Background

Borg Backup UI currently invokes borg create with the fixed setting:

--files-cache=ctime,size

This already ignores inode values, which avoids one source of unnecessary cache misses on filesystems with unstable inode information. However, ctime can change after metadata-only operations even when file content is unchanged.

A user reported that --files-cache=mtime,size substantially reduced repeated file processing for backups sourced through Unraid /mnt/user. This is technically plausible, but it has not been proven that Unraid shfs or Mover is the cause in that installation.

Borg documents an important safety tradeoff: mtime,size can miss a content change when both the file size and mtime remain unchanged or are restored.

Goal

Allow an advanced per-job selection between the current ctime,size behavior and mtime,size, while keeping the existing safer behavior as the default and clearly explaining the risk of the alternative.

Proposed scope

• Add an advanced Borg files cache setting to backup jobs.
• Initially expose only:
  • ctime,size - safer default; may reprocess files after metadata-only changes.
  • mtime,size - may reduce such processing, but can miss changes when size and mtime are unchanged.
• Keep ctime,size as the default for new jobs.
• Treat a missing setting in existing job files as ctime,size so upgrades do not change behavior.
• Validate the value against an explicit allowlist in both UI and backend.
• Pass the selected value to borg create.
• Show the selected mode in the job summary or flow preview.
• Add localized German and English help text.
• Document the setting and its tradeoff in both user manuals.

The Borg modes containing inode values, rechunk,*, and disabled are deliberately outside the initial scope. They need separate use-case and safety analysis before being exposed in the normal job wizard.

Required warning

When mtime,size is selected, show a prominent warning similar to:

This mode only uses modification time and file size for the files cache. It can reduce repeated file processing after metadata-only changes, but Borg may miss a content change if both size and mtime remain unchanged or are restored. Use this expert option only if you understand this tradeoff.

The wording must not claim that Unraid Mover or shfs is definitively responsible for the observed metadata changes.

Acceptance criteria

• Existing jobs without the new field continue to use ctime,size.
• New jobs default to ctime,size.
• Users can explicitly select mtime,size per job.
• Selecting mtime,size displays a clear German and English safety warning before the job is saved.
• Unsupported or manipulated values are rejected by backend validation.
• The generated borg create command uses exactly the selected allowlisted mode.
• Job duplication, editing, import/export, and flow preview preserve or display the setting correctly.
• Tests cover defaults, legacy job data, both allowed values, invalid values, and command construction.
• Both user manuals explain the difference without presenting mtime,size as universally better or as the new default.
• User-visible release notes are added.

Validation notes

Before considering a default change in any later issue, run controlled comparisons with unchanged content, metadata-only changes, a Mover operation, and an intentional same-size content change with preserved mtime.