feat(seer): Link failing checks to their runs on autofix overview

[NicoHinderling]

Warning

Blocked on #122486 (backend) — do not merge until that PR is deployed.
This reads the failedCheckDetails API field added by #122486. Per the split-deploy rule (AGENTS.md), the backend must land and deploy first. Opened as a draft for early review.

Summary

The Autofix Overview's "N Checks Failing" tooltip lists each failing PR check by name as dead text. This makes each check name a link to its CI run, so a user can jump straight from a failing check to the run that failed.

What changed

• types.ts: adds FailedCheckDetail { name, url } and an optional failedCheckDetails field on OverviewPullRequest.
• issueCard.tsx: the failing-checks tooltip renders each check name as an ExternalLink to its run URL when one is present; checks without a URL stay plain text. The tooltip is already hoverable by default, so the links are clickable.

Deploy dependency

Reads only failedCheckDetails (no name-only fallback), so it hard-depends on #122486 being deployed first — which is the required merge order anyway. A failing check whose provider gives no run URL renders as plain text.

Note: the backend validates that each url is http(s)-only (see #122486), preventing a javascript:/data: scheme from reaching the anchor href.

Follow-up cleanup

The redundant failedChecks names field is removed from the backend in the stacked cleanup PR #122490 (merges after this deploys).

Tests

Extends index.spec.tsx: a failing check with a run URL renders an anchor to that URL; a check with url: null stays plain text; a failing PR with no check details shows the plain "Checks Failing" label.

[sentry]

Bug: The Tooltip for failing checks is missing isHoverable={true}, causing it to close immediately when the user tries to move their cursor to click the links inside.
_{Severity: MEDIUM}

Suggested Fix

Add the isHoverable={true} prop to the Tooltip component in issueCard.tsx. This will ensure the tooltip remains open long enough for the user to move their cursor from the trigger tag to the tooltip content and interact with the links inside.

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: static/app/views/seerWorkflows/overview/issueCard.tsx#L258-L274

Potential issue: The `Tooltip` component used to display failing checks is not
explicitly configured with `isHoverable={true}`. The underlying `useHoverOverlay` hook
requires this prop to apply a delay before closing the tooltip when the mouse leaves the
trigger element. Without this delay, when a user hovers over the "Checks Failing" tag
and then moves their mouse towards the tooltip's content to click a link, the tooltip
will close instantly. This makes the links to the failing checks inaccessible to the
user, rendering a key part of the new functionality unusable.

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

[NicoHinderling]

Not applicable here — Tooltip from @sentry/scraps/tooltip already defaults isHoverable = true (tooltip.tsx:49) and threads it into useHoverOverlay (tooltip.tsx:64). So this tooltip is hoverable without an explicit prop, and the links are reachable. The RTL test hovers the tag and asserts the run link is present/clickable. No change needed.

[sentry]

Bug: The frontend now only reads failedCheckDetails, but the backend still sends failedChecks. If deployed before the backend, failing check details will be silently lost.
_{Severity: MEDIUM}

Suggested Fix

To ensure backward compatibility and prevent data loss during the deployment transition, the frontend should be updated to handle both the new and old fields. Check for failedCheckDetails first, but if it's not present, fall back to using the data from the failedChecks field. This will ensure the feature works correctly regardless of the deployment order of the frontend and backend changes.

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: static/app/views/seerWorkflows/overview/issueCard.tsx#L211-L217

Potential issue: The frontend has been updated to exclusively read the
`failedCheckDetails` field from the API response, removing support for the old
`failedChecks` field. However, the backend has not yet been updated and still sends
`failedChecks`. If this frontend change is deployed before the corresponding backend
update, the `failedCheckDetails` field will be `undefined` in the API response. The code
will then fall back to an empty array `[]` due to the nullish coalescing operator. This
causes the UI to correctly indicate that checks are failing, but the list of specific
failing checks will be empty, resulting in a silent loss of information for the user.

Also affects:

• static/app/views/seerWorkflows/overview/types.ts:159~165

[NicoHinderling]

By design, and safe under our deploy order. The name-only failedChecks fallback was intentionally removed so the frontend reads only failedCheckDetails. The silent-loss window described here only exists if this ships before the backend — which the merge order prevents: this PR is gated on #122486 (which adds failedCheckDetails) landing and deploying first (it is a draft with a blocked-on banner). Once #122486 is live, every response includes failedCheckDetails, so there is no frontend-new / backend-old window. No change.