feat(supergroups): add issues-with-supergroups endpoint

[cvxluo]

Add a new 'issues' endpoint for a blended issues + supergroups view. This works by fetching x2 results, combining issues that are in the same supergroups, and then fetching that exact number to get the correct cursor for the next page.

Unfortunately this approach requires 2 search queries over basically the same data. The problem is maintaining the cursor here. Let's say we get a request for 25 results and fetch 50. We blend together to get 25 rows, using 40 of the original groups we fetched. We don't have a cursor to return at the 40th result, since each time we fetch a page, we get the cursor from the end of the page — we only have the cursor at 50. To fix this, we make another request for the number of issues we actually used, then modifying that cursor to work accordingly.

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

[yuvmen]

looks good overall, I think this works as like a best effort to make this viable for now.

[yuvmen]

minor - can add information as a comment on the endpoint so its more visible, this x-hits behaviour that might be kinda hidden

[cvxluo]

going to skip for now, agree that it's not great behavior in general. i'm kind of hoping we are able to fix this with a more holistic solution before we have to deal with it seriously

[yuvmen]

minor - we technically dont need to serialize here cuz we dont use the issues we get and its kind of a heavy operation, dont think it exists but we could actually do a search_only method just for this purpose, and save the serialization, kinda alleviating some of the pain of this second fetch

[yuvmen]

feel like we should have a parallel test to this where a page does include a supergroup to make sure the cursor gets updated correctly

[sentry]

Bug: A user can pass limit=0, causing a second search_issues call to also be made with limit=0. This is an invalid state that can lead to incorrect results.
_{Severity: LOW}

Suggested Fix

Prevent limit=0 at the input validation stage on line 49 by changing max(0, ...) to max(1, ...). Alternatively, ensure the second search_issues call never receives a limit less than or equal to zero.

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/issues/endpoints/organization_issues_with_supergroups.py#L49

Potential issue: The endpoint allows a user to pass `limit=0` as a query parameter. When
this happens, the `_combine_groups_and_supergroups` function returns `last_consumed=-1`.
This state triggers a second call to `search_issues` around line 110, but with `limit`
set to `0`. While the search backend might not crash, other paginators in the codebase
explicitly raise an error for `limit <= 0`, indicating this is an unsupported and
problematic state that can lead to empty or incorrect results.

Also affects:

• src/sentry/issues/endpoints/organization_issues_with_supergroups.py:110~122

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