I'm concerned about the maximum storage need of Staggered File Versioning. If I understand correctly, for the first 1 hour alone a maximum um 120 copies might be kept, and for the first day 24 additional, meaning with only 1 day Maximum Age, one would need to ensure the 144 fold storage space of the synced folder to be save. Otherwise an adversary (human or software e.g. ransomware) can prevent any syncing by flooding the versioned storage.
While I do not doubt that there are use cases where the current setup is ideal and either backed by sufficient storage or the risk is acceptable, I would like to suggest and ask for making the staggered intervals configurable, which would be also in general a welcome increase in flexibility with very limited additional code complexity.

fields to allow configuring interval (i.e. parameterize line 50 to 53 of staggered.go (https://github.com/syncthing/syncthing/blob/main/lib/versioner/staggered.go)

			{30, 60 * 60},                     // first hour -> 30 sec between versions
			{60 * 60, 24 * 60 * 60},           // next day -> 1 h between versions
			{24 * 60 * 60, 30 * 24 * 60 * 60}, // next 30 days -> 1 day between versions
			{7 * 24 * 60 * 60, maxAge},        // next year -> 1 week between versions

(Users can tune the staggering to their usecase, and syncing needs resulting in e.g.
{15 * 60, 2 * 60 * 60}, //first 2 hours -> 15min between version
{2 * 60 * 60, 24 * 60 * 60} //next day -> 2h between versions,
...

So one would need a input table with two columns and fixed or variable number of rows:
bin | duration
30 | 3600
3600 | 86400
86400 | 2592000
604800 | maxAge
would be the current setup (and then default)

Advantage:

• parameterization should not be to hard and no other changes to the code or test needed
• adjustable usecases, storage and risk settings

This suggestion would also solve #4717

Please consider and many thanks for this great piece of software