fix(objectstore): propagate attachment retention

[matt-codecov]

objectstore clients in Relay and Sentry are hardcoded to use 30d TTL retention for all attachments. we need to instead inherit the correct retention policy from the event/envelope/project/whatever.

questions:

• are ctx.event_retention().standard and envelope.envelope().retention() the correct places to inherit the retention policy from?
• what are trace attachments? usage of the type is not clear to me

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[sentry]

Bug: An integer overflow in the retention duration calculation can cause silent data loss if the retention period exceeds 2730 days, as retention * 24 overflows a u16.
_{Severity: HIGH}

Suggested Fix

Cast the retention variable to u64 before performing the multiplication to prevent the integer overflow. The calculation should be Duration::from_hours(retention as u64 * 24).

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: relay-server/src/services/objectstore.rs#L532-L535

Potential issue: In the attachment retention duration calculation, the `retention`
variable is a `u16`. The expression `retention * 24` is calculated using 16-bit
arithmetic before being converted to a 64-bit integer. If `retention` is set to a value
greater than 2730 days, this multiplication will overflow. In release builds, this
overflow will wrap silently, resulting in a drastically shorter retention period than
intended (e.g., 2731 days becomes approximately 8 hours), leading to premature data
deletion. In debug builds, this will cause the service to panic and crash.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Potential u16 overflow in retention-to-hours multiplication

Medium Severity

The expression retention * 24 performs multiplication in u16 space since retention is u16 and 24 is inferred as u16. The .into() only widens to u64 after the multiplication. Any retention value above 2730 days causes a panic in debug or silent wraparound in release, resulting in an incorrect (much shorter) TTL and premature data deletion. The existing retention_days_to_duration helper in normalize.rs avoids this by casting to u64 before multiplying — the same pattern of widening first is needed here.