feat(seer): Add the stopping-point field to project-specific seer settings

[ryan953]

This brings in the stopping-point dropdown to the project-specific seer settings page

Follows: #112211

There's still more to cleanup in here, but we're well on the way.

[ryan953]

This wasn't staying up to date with the actual queryKey in use. We're fetching infinite data, so things would've never matched here.

Requiring the proper ApiQueryKey type for invalidateQueries is something i want to followup on across the whole codebase, that should encourage more use of apiOptions and similar

[ryan953]

again, wrong query key. People ideally shouldn't be doing string-interpolation for api urls anymore.

[ryan953]

same logic as getDefaultStoppingPointValue above, just with different field names

having the names align is a goal as we update the endpoints, but not for this PR :(

[sentry]

Bug: The optimistic cache update for Seer preferences spreads the entire SeerPreferencesResponse into the preference field, creating a malformed cache object with a nested structure.
_{Severity: MEDIUM}

Suggested Fix

In the optimistic update logic, instead of spreading the entire preferencePayload, spread the inner preferencePayload.preference object to match the expected ProjectSeerPreferences type for the preference key.

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/settings/seer/overview/utils/seerStoppingPoint.ts#L192-L198

Potential issue: The optimistic cache update for Seer preferences incorrectly spreads
the entire `preferencePayload` object, which is of type `SeerPreferencesResponse`, into
the `preference` field. This field is expected to be of type `ProjectSeerPreferences`.
This data structure mismatch creates a malformed cache object with a nested `preference`
key and misplaced `code_mapping_repos`. This will cause the UI to render with incorrect
data until the cache is invalidated and refetched, potentially leading to transient
display errors or type errors when accessing preference fields.

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

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

[cursor]

Cache update spreads wrong object into preference field

High Severity

In the onSuccess handler for getProjectStoppingPointMutationOptions, preferencePayload (a SeerPreferencesResponse) is spread directly into the preference object when updating the query cache. This corrupts the cache by incorrectly injecting code_mapping_repos and a nested preference object into the preference field.

 

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