feat(eap): drop out of range data.

[tryangul]

What

Re-adds the out-of-range timestamp drop removed in #8222, but bounded by item retention instead of a flat 30 days.

How

• eap_items_drop_invalid_timestamps option is back, default false
• eap-items processor drops items older than retention_days or >7d in the future, before the age DLQ check
• Accepted outcomes aggregator applies the same check so dropped items aren't billed
• *.dropped_out_of_range_timestamp{reason, item_type} metrics restored. reason:past_ts|future_ts matches dlqed_prior_partition
• out_of_valid_interval_secs rewritten for readability. Boundaries are the same (exactly-at-retention / exactly +7d are kept)

Why

• Reduces load on CH and ZK caused by tiny parts for old data that's dropped by TTLs immediately
• We have backlog of old date in the DLQ we need to burn down which would otherwise inflict a bunch of tiny part load on us

Notes

• Known limitation, same as before ref(eap-items): remove eap_items_drop_invalid_timestamps #8222: both consumers check against their own Utc::now() and read the option independently. Different lag means a message can be dropped by one and kept by the other around the flip or right at a boundary. Should be negligible.

Links

• Relates to: INC-2585: https://app.notion.com/p/sentry/INC-2585-Max-parts-per-partition-high-3f98b10e4b5d817f9187ceed60c3c3e8

[linear-code]

INC-2585

[tryangul]

Note: Result<Option< is a bit of a code smell, but this keeps the diff tight and unblocks us in the interest of time / effort (things will start aging out the the DLQ in a little over 24 hours)