header/sync: revisit recencyThreshold default based on measured ingestion lag

Once header store lag data is available from production deployments, revisit the `recencyThreshold` parameter used by `header/sync` and choose a new value (or configuration policy) based on measurements rather than on the current `blockTime * 2` heuristic.
The current default `recencyThreshold` (`blockTime * 2`) has been observed to trigger the `non recent subjective head` / `non recent head from trusted peers` warning path on healthy bridge nodes during normal operation. The warning leads to redundant `Head` requests against trusted peers and adds operational noise that is difficult to act on. The root cause is a structural mismatch: `Header.Time()` is a BFT median timestamp that is already ~`blockTime` behind the actual moment the block
appears on chain, leaving the ingestion pipeline a budget of only ~`blockTime` before the threshold is tripped. This budget is frequently exceeded under realistic conditions (large blocks, load, cross-region network paths) even when the node is functioning correctly. Rather than guessing a new value, we want to base the decision on actual distribution of ingestion latency observed across deployments.