fix(seer): Propagate Explorer failure reasons

[gricha]

Preserve timeout and stalled failure reasons when Sentry parses Seer run state, allowing the Explorer chat API to expose the terminal cause to the frontend.

Seer begins emitting these reasons in getsentry/seer#7911, but Sentry's Pydantic boundary previously discarded the unknown field. The field remains optional for compatibility with older Seer responses. This unblocks the timeout recovery UI in #122934.

[sentry]

Bug: An unrecognized failure_reason from the Seer API will cause a ValidationError that is incorrectly handled as a 404 Not Found, masking the true error.
_{Severity: MEDIUM}

Suggested Fix

Explicitly catch pydantic.ValidationError in the endpoint to handle this case separately from a generic ValueError. Alternatively, make the SeerRunState model more lenient by removing the strict Literal and allowing any string, to ensure forward compatibility with the Seer API.

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/agent/client_models.py#L267

Potential issue: The `SeerRunState` Pydantic model defines the `failure_reason` field
with a strict `Literal["timeout", "stalled"]`. If the external Seer API sends a new,
unrecognized failure reason, Pydantic will raise a `ValidationError` during response
parsing. Because Pydantic v1's `ValidationError` is a subclass of `ValueError`, this
exception is caught by a generic `except ValueError` block in the endpoint. This handler
incorrectly returns a 404 Not Found response, which makes it appear to the client that
the run does not exist, when it actually does. This masks the true error and leads to a
misleading state for the user.

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