Reconsider the 60-day default for worker.historyScannerDataMinAge (or document its rationale)

worker.historyScannerDataMinAge (default 60 days) sets how old an orphaned history branch must be before the history scanner ("scavenger") will reclaim it. Orphaned branches include history left behind by rejected or deduplicated StartWorkflowExecution calls.

With the 60-day default, this leftover — which is pure garbage once the workflow record is gone — sits for up to two months before the scavenger will touch it. On clusters where it accumulates (for example high-volume workflow-id-based deduplication with REJECT_DUPLICATE), operators typically need to lower this to hours to keep the history_node / history_tree tables from growing.

Request here is to lower default of worker.historyScannerDataMinAge to something less conservative. One week would imho be OK option.
Reason is that currently most of on-prem users don't know this dynamic exists so they do not explicitly change it and just use default.
There is no real guidance on how low this dynamic config should also be set. Having some guidance would really help as well.

Start by locating the definition and uses of worker.historyScannerDataMinAge, then read how the history scanner reclaims orphaned branches. Determine an appropriately lower default and add guidance explaining the setting and its tradeoffs. Done means the default and operator documentation reflect the decision, with relevant validation for history_node and history_tree cleanup.