feat(profiling): Add support for profiling chunk attachments

[markushi]

Continuous-profiling chunks can now carry attachments (e.g. Perfetto system traces). Relay stores the attachment blob directly in Objectstore under the profile_attachments usecase (requires getsentry/relay#6108 to merged first) and forwards the resulting key on the profile-chunk Kafka message.

This PR persists a lightweight ProfileChunkAttachment row referencing that blob and exposes endpoints to list and download attachments, heavily inspired by the events attachment endpoint.

The whole feature is gated behind the new organizations:continuous-profiling-perfetto flag.

The blob itself is owned by Objectstore and reclaimed via its TTL, so we only store metadata plus the stored_id. date_expires mirrors the chunk retention and the model is registered for expiry-based cleanup.

Two endpoints are added:

• GET .../organizations/{org}/profiling/chunk-attachments/ lists attachments for a profiler's chunks, including per-attachment metadata. The visible chunks are resolved from profiler_id and the time range using the same logic as the flamegraph, so results match what is rendered.

• GET .../projects/{org}/{project}/profiling/chunks/{profiler_id}/{chunk_id}/attachments/{id}/?download streams the attachment blob. The ?download query parameter is required (a request without it returns 400), keeping the contract consistent with EventAttachmentDetails. Access requires the organization's configured attachments role, mirroring EventAttachmentDetailsPermission, since traces can contain sensitive data. Per-attachment metadata is served by the list endpoint above, so this endpoint is download-only.

[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.

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/migrations/1118_profilechunkattachment.py

for 1118_profilechunkattachment in sentry

--
-- Create model ProfileChunkAttachment
--
CREATE TABLE "sentry_profilechunkattachment" ("id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, "project_id" bigint NOT NULL, "profiler_id" varchar(36) NOT NULL, "chunk_id" varchar(36) NOT NULL, "name" text NOT NULL, "content_type" text NULL, "stored_id" text NOT NULL, "date_added" timestamp with time zone NOT NULL, "date_expires" timestamp with time zone DEFAULT ((STATEMENT_TIMESTAMP() + '30 days 0.000000 seconds'::interval)) NOT NULL);
CREATE UNIQUE INDEX CONCURRENTLY "sentry_profilechunkattach_unique" ON "sentry_profilechunkattachment" ("project_id", "profiler_id", "chunk_id", "stored_id");
ALTER TABLE "sentry_profilechunkattachment" ADD CONSTRAINT "sentry_profilechunkattach_unique" UNIQUE USING INDEX "sentry_profilechunkattach_unique";
CREATE INDEX CONCURRENTLY "sentry_profilechunkattachment_date_expires_11beddd2" ON "sentry_profilechunkattachment" ("date_expires");

[markushi]

@sentry review