feat(issues): Add issue.autofix_state search key for autofix overview

[NicoHinderling]

Adds a Postgres-only issue-search key, issue.autofix_state, that classifies issues into five mutually exclusive autofix pipeline states:

• merged — the group's latest autofix run has a merged PR (via the SeerAgentRun → SeerRun → SeerRunPullRequest → PullRequest.state join, webhook-fresh and flag-free)
• review_pr — SEER_PR_CREATED activity exists, PR not merged
• code_changes_ready — SEER_CODING_COMPLETED, no PR yet
• solution_ready — SEER_SOLUTION_COMPLETED, no code yet
• needs_investigation — a Seer run in the last 30 days with none of the above

The autofix overview page currently classifies issues client-side by fetching each issue's full run state from Seer (two Seer round trips per issue per page load), which makes true per-section counts and server-side filtering impossible. With this key, each overview section becomes a plain filtered issue-stream query with real counts from X-Hits. Milestone signals come from the SEER_* activity rows Sentry already records when Seer pushes step-completion events; precedence is baked into the conditions so every seer-touched issue lands in exactly one state.

The filter logic lives in a Seer-owned module (sentry/seer/autofix/issue_search.py); registration mirrors issue.progress at the standard three points (value converter, QCallbackCondition, SKIP_SNUBA_FIELDS). No migration (the join is already indexed), no new flags, no behavior change for any existing query.

Performance notes (verified against compiled SQL + prod indexes): milestone subqueries hit Activity's (project_id, type) index and plan as hashed anti-joins (NULL-guarded); the Postgres candidate query is capped at 5k. Two known plan-shape assumptions: the merged join relies on the planner anchoring on SeerAgentRun.project_id (PullRequest.state is unindexed), and needs_investigation has no positive anchor — its scan is bounded by the standard issue-search indexes, same cost model as issue.progress.

The frontend consumer (per-section fetches on the autofix overview) follows in a separate PR.

[trevor-e]

Approving to unblock you since this isn't wired up anywhere but I would confirm with the issues team before merging. I don't know the downstream ramifications of registering a new search key. I would look into revising the query before merging as well.

[trevor-e]

I think this is going to result in a pretty inefficient query that might not work in prod. I tested compiling the SQL for this and it repeats the JOIN and IN parts several times. You may want to pull some of this into a CTE first and go from there.

[NicoHinderling]

I've now collapsed the repeated milestone queries into a single GROUP BY group_id HAVING scan per state (a95ed1d), since Django's ORM can't express CTEs.

Worst-case single-state query went from 5 subqueries (3 duplicate Activity scans) to 3, and each compiles to hashed subplans over the (project_id, type) index so they execute once per query, not per row. The UI only ever queries one state at a time, so that bounded shape is the hot path.

FWIW though the subplans are hashed and run once per query, not per row, each over the (project_id, type) index with the candidate set capped at 5k, so even without the consolidation, it was already bounded and should still be fast from what i can tell

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

^{Reviewed by Cursor Bugbot for commit 58a914f. Configure here.}