feat(seer): Record a night shift result row for every triage verdict

[trevor-e]

Night shift previously persisted SeerNightShiftRunResult rows only for AUTOFIX verdicts whose trigger succeeded — SKIP and ROOT_CAUSE_ONLY verdicts, failed triggers, and dry runs existed only in log lines, so verdict outcomes couldn't be analyzed from the database.

Delivery now writes one row per verdict in a single bulk_create: extras carries the action and a capped reason; autofix verdicts additionally link result_seer_run on success or set extras["trigger_error"] when the trigger raised. Dry runs persist rows too.

Supporting changes:

• Redelivery is now idempotent. Delivery skips groups that already have a row for the run. Seer re-delivers shard results whenever a deploy kills a worker holding an unacked task, and each redelivery previously re-triggered autofix for every AUTOFIX verdict and wrote duplicate rows. The bulk_create passes ignore_conflicts=True for the (run, group) unique constraint landing in feat(seer): Scope night shift result dedupe to (run, kind, idempotency_key) #119141 (stacked; merges after this deploys).
• The autofix trigger loop moved from cron.py into delivery's _process_verdicts — delivery was its only caller, previously reached through a circular-import workaround.
• The run's extras now stamp num_eligible_projects and num_candidates, so zero-shard runs are distinguishable: no eligible projects vs. no scored candidates vs. dispatch failure.

No API or frontend changes needed: the issues payload already exposes extras["action"] and the UI has labels for every action, so the Explorer now shows the full triage picture instead of only autofixed issues.

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/seer/migrations/0026_dedupe_night_shift_run_results.py src/sentry/seer/migrations/0027_unique_night_shift_result_run_group.py

for 0026_dedupe_night_shift_run_results in seer

--
-- Raw Python operation
--
-- THIS OPERATION CANNOT BE WRITTEN AS SQL

for 0027_unique_night_shift_result_run_group in seer

--
-- Create constraint seer_nightshiftrunresult_unique_run_group on model seernightshiftrunresult
--
CREATE UNIQUE INDEX CONCURRENTLY "seer_nightshiftrunresult_unique_run_group" ON "seer_nightshiftrunissue" ("run_id", "group_id") WHERE "group_id" IS NOT NULL;

[sentry]

Bug: bulk_create with ignore_conflicts=True is used without a database unique constraint, allowing concurrent redeliveries to create duplicate rows due to a race condition.
_{Severity: MEDIUM}

Suggested Fix

Deploy the database migration that adds the UniqueConstraint on (run, group) to the SeerNightShiftRunResult model. This will make the ignore_conflicts=True parameter effective and prevent duplicate row creation at the database level, resolving the race condition.

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/seer/night_shift/delivery.py#L237

Potential issue: The code at `delivery.py:237` calls `bulk_create` with
`ignore_conflicts=True`, but the corresponding `(run, group)` unique constraint on the
`SeerNightShiftRunResult` model does not exist in the database yet. Without this
constraint, `ignore_conflicts=True` has no effect. An idempotency check on lines 134-138
is insufficient to prevent duplicates under concurrent redeliveries. A
time-of-check/time-of-use (TOCTOU) race condition exists where two workers can both
check for existing rows (finding none), and then both proceed to insert the same data,
resulting in duplicate `SeerNightShiftRunResult` rows.

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

[trevor-e]

fixing in a stacked PR follow-up

[chromy]

lgtm