feat(preprod): Add build distribution CSV export endpoint

[jamieQ]

Backend half of EME-1035: a streaming CSV export of build distribution stats.

GET /organizations/{org}/builds-export/ streams a CSV of the installable builds matching the current query, project, and date-range filters. It is scoped to the build-distribution view (non-snapshot builds) and ignores any display param. It shares a new filtered_builds_queryset() helper with the builds list endpoint so filtering can't drift, then narrows to installable builds — reusing the same is_installable_artifact() check the list uses for its is_installable flag, so the export matches what the UI labels installable — and streams through CsvResponder without the list's heavy per-row work (base-artifact lookup, size metrics, snapshot derivation).

Exports over 10,000 rows are rejected with a 400 rather than silently truncating. Cells are escaped against formula injection and the endpoint is rate-limited.

Columns: app_name, project_slug, artifact_id, app_id, build_configuration, version, platform, install_groups, upload_date, download_count — mirrors the original Emerge report, with project_slug inserted after app_name. build_configuration is the configuration name (e.g. "Debug"/"Release"), blank when the build has none.

Corresponding frontend changes to come in a subsequent PR.

Refs EME-1035

[linear-code]

EME-1035

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

[NicoHinderling]

perhaps we can rename this to "get_preprod_retention_cutoff` since snapshots and size retention rules will be the same and we're using them for both potential cases here

[jamieQ]

I'll follow up with a rename in another PR since it's used in a number of spots

[sentry]

Bug: The CSV export for builds will always report a download_count of 0 because the database query is missing the necessary annotation to calculate this value.
_{Severity: MEDIUM}

Suggested Fix

Add the .annotate_download_count() method to the queryset chain in src/sentry/preprod/api/endpoints/builds_export.py between lines 143 and 145. This will ensure the download_count is correctly calculated and included in the exported CSV.

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: src/sentry/preprod/api/endpoints/builds_export.py#L143-L145

Potential issue: The CSV export for builds consistently reports a `download_count` of 0
for all artifacts. This occurs because the database queryset at lines 143-145 does not
include the `.annotate_download_count()` method. As a result, the `download_count`
attribute is not present on the model instances being iterated over. The code then falls
back to `getattr(item, "download_count", 0)`, which returns the default value of 0,
leading to incorrect data in the exported file.

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

[jamieQ]

BuildsExportEndpoint.get() builds its queryset via filtered_builds_queryset(), which traces back to the annotation:

builds_export.py:120 → filtered_builds_queryset(...)
builds_query.py:37 → queryset_for_query(query, organization)
artifact_search.py:222 → apply_filters(_base_searchable_queryset(), ...)
artifact_search.py:191-198 → _base_searchable_queryset() calls .annotate_download_count()