feat(seer): Record prompt version on night shift deliveries

[trevor-e]

Night shift triage results can now be attributed to the prompt revision that produced them. deliver_feature_result accepts an optional Seer-reported prompt_version string, and the night shift handler records it in the shard's extras — on every delivery, errors included, since failed runs write no result rows — and denormalized onto each SeerNightShiftRunResult row, so verdict quality and error rates can be grouped by prompt version without a join. The smart_assignment and autofix handlers accept the kwarg and ignore it for now.

This ships ahead of the Seer-side change, which will add a PROMPT_VERSION constant to the night shift feature and pass it on result push. Deploy order matters: Seer must not send the kwarg until this is deployed, as the RPC dispatch would reject the unknown argument and lose the delivered result. Older Seer versions simply omit it and nothing is recorded.

[sentry]

Bug: A stale read of shard.extras between two update() calls can cause the prompt_version to be lost when clearing a pre-existing error message on a shard.
_{Severity: MEDIUM}

Suggested Fix

Refresh the shard object from the database after the first update() call by calling shard.refresh_from_db(). This will ensure that the in-memory shard.extras is up-to-date before the logic that decides whether to perform the second update, preventing the stale data from overwriting the prompt_version.

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#L75-L82

Potential issue: The function `deliver_night_shift_result` can perform two separate
`shard.update()` calls on the `extras` field. The first update, which may add a
`prompt_version`, modifies the database directly but does not refresh the in-memory
`shard` object. If the shard had a pre-existing error, a second update is triggered to
clear it. This second update reads the stale `shard.extras` from the in-memory object,
which lacks the new `prompt_version`. It then writes a modified version back to the
database, overwriting the `extras` field and silently deleting the `prompt_version` that
was just added. This occurs during retry scenarios where a failed delivery is followed
by a successful one.

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

[trevor-e]

My clanker doesn't think this is an issue with Sentry's version of BaseModel.