ref(groupresolution): order releases by date_released when it is set

[stigi]

Draft, and deliberately so: this is a behaviour change rather than a pure bug fix, and I'd like direction on how you'd want it gated before it's worth polishing. Opening it mainly so #47218 has something concrete attached.

Fixes the inconsistency in #47218 (open since 2023; #9771 reported the same in 2018): the releases endpoints order by COALESCE(date_released, date_added), but GroupResolution.has_resolution compares date_added alone. Both are called "release order" in the UI, and they disagree.

The problem

date_added is when Sentry first saw a release, not when it shipped. A release row created by an incoming event from an old build carries a recent date_added, so it outranks the release that actually fixed the issue, and the issue reopens.

From our org today:

regressor  2.102.0-stable.5+ci7642794   date_added 2026-09-02   date_released 2025-12-01
fix        2.132.0-stable.3+ci8156657   date_added 2026-06-18   date_released 2026-06-18

The regressing build shipped nine months before the fix and its dateReleased says so, but the row was only created on 2026-09-02 when an old client first sent an event. The activity feed calls the reopening "based on release order".

Finalizing does not help, because the resolution path never reads the field. There is no workaround either: date_added is not settable through the API — the release serializer ignores dateCreated/dateAdded while accepting dateReleased in the same request.

The change

One helper, release_order_date(date_added, date_released), used at the four places has_resolution compares dates. It mirrors the COALESCE the releases endpoints and most_recent_release already use, so both meanings of "release order" agree.

Three tests cover a release added late but finalized with an earlier ship date, for in_release and in_next_release, and for a resolution whose own release was late-registered.

What I need direction on

• Gating. This changes which issues reopen for any org that has finalized releases with dates differing from date_added. Should it sit behind a feature flag or an org option rather than shipping unconditionally?
• Scope. I left most_recent_release and the semver paths alone. get_current_release_version_of_group may deserve the same treatment.
• Testing. I have not run your suite — it needs the devservices stack. The tests mirror the existing ones in that file and create_release accepts date_released, but they are unverified. Happy to iterate if CI disagrees.

Context: we hit this after backfilling dateReleased onto 3,301 historical releases from our CI's build manifest. It corrected the Releases list ordering and changed nothing about regressions.