ref(seer): Refactor night shift into modules and use search backend

[trevor-e]

Refactors night shift from a single file into a package with separate modules for cron scheduling, simple triage, agentic triage, and shared models.

Switches fixability_score_strategy from a direct ORM query to using search.backend.query() with the recommended sort. This gives us the same ranking algorithm used in the issues list UI (recency, spike detection, severity, user impact, event volume) as a pre-filter, then re-ranks by fixability score in-memory.

Other changes:

• Adds reset_snuba_data flag to SnubaTestCase so tests can opt out of dropping ClickHouse data between runs
• Adds bin/seer/trigger-night-shift script for local testing
• Registers a new Snuba referrer for the search query
• Uses pydantic model_validate_json for LLM response parsing in agentic triage

[trevor-e]

This was driving me insane. Running tests should not reset your entire devbox's data.

[chromy]

🥲 🥲 🥲

[sentry]

Bug: The new search filter for issue.seer_last_run only checks one of two timestamp fields, allowing previously processed issues to be re-triaged, unlike the old logic which checked both.
_{Severity: HIGH}

Suggested Fix

Modify the search query to ensure it checks both seer_autofix_last_triggered and seer_explorer_autofix_last_triggered for null values, restoring the original behavior. This will prevent issues processed by either Seer pathway from being re-selected for triage.

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/tasks/seer/night_shift/simple_triage.py#L59-L63

Potential issue: The refactored `fixability_score_strategy` function changes the logic
for filtering previously processed Seer issues. The new `SearchFilter` for
`issue.seer_last_run` resolves to checking only one of two timestamp fields
(`seer_autofix_last_triggered` or `seer_explorer_autofix_last_triggered`) based on a
feature flag. The previous implementation correctly checked for null values in both
fields. This regression means that an issue processed by one Seer pathway can be
incorrectly re-selected for triage by the other, leading to duplicated work and wasted
compute resources.

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

[trevor-e]

This is fine, we can re-run an explorer client run even if they had a legacy run.

[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 7d9b2a5. Configure here.}

[cursor]

Seer last run filter checks only one field

Medium Severity

The old ORM query filtered on both seer_autofix_last_triggered__isnull=True AND seer_explorer_autofix_last_triggered__isnull=True, ensuring groups triggered by either mechanism were excluded. The new issue.seer_last_run search filter maps to a ScalarCondition that only checks one of those fields based on the organizations:autofix-on-explorer feature flag. This means groups previously processed via the other code path could be re-selected as candidates, leading to duplicate processing.

 

^{Reviewed by Cursor Bugbot for commit 7d9b2a5. Configure here.}

[trevor-e]

Same as above, this is fine and we can re-run an explorer client run even if they had a legacy run.

[chromy]

lgtm

[chromy]

temperature=0.0 on purpose here?