feat(seer): Rewrite the Seer > Project list page

[ryan953]

This rewrite consolidates some of the previous columns to match what's in #109349

• We've combined the previous "auto-triggered fixes" and "coding agent" columns into one column with a dropdown to pick an "Autofix Agent".
• PR create column now applies to background agents as well as Seer Agent

Bulk editing is disabled. At this moment we don't have support for updating the complex automation_handoff values in the current bulk edit endpoint.

Fixes https://linear.app/getsentry/issue/CW-930/settings-seer-project-list-simplify-the-columnsactions-to-match
Depends on #110188

[linear]

CW-930 Settings > Seer > Project List: Simplify the columns/actions to match project details

[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.}

[billyvg]

Are we intending on adding bulk edit back?

[ryan953]

yeah, i can followup and do a jank verison i think but ideally we land the v3 api's defined here: https://github.com/getsentry/sentry/pull/109532/changes#diff-2264702ce85b219d3290a3f4a4e63380abb4961a7f3add98e0cad8540c7489d3 @srest2021 is gonna take a look!

the v2 apis area what we have, and they don't support setting background agent in bulk, we'd need have a loop or something to make the calls on a per-row basis. For small orgs that wouldn't be tooooo bad as a stopgap. i'll followup today on it.

[billyvg]

do we want/need a useCallback for these onChange handlers?

[ryan953]

Clanker says we're ok:

No, you don't need useCallback here, and this is fine as-is. Here's the reasoning:

When useCallback matters:

useCallback prevents a function from being re-created on every render. This only matters when the function identity is used as:

A dependency in another hook (useEffect, useMemo, etc.) -- a new reference would cause the effect/memo to re-run.
A prop to a memoized child (React.memo) -- a new reference would defeat the memoization and cause a re-render.
A value in a context -- a new reference would cause all consumers to re-render.
Why it doesn't matter here:

Select is not wrapped in React.memo in any way that would benefit from stable onChange references. Even if it were, the parent (SeerProjectTableRow) re-renders infrequently -- only when its props change (autofixSettings, integrations, project, isPendingIntegrations).
The onChange isn't passed as a dependency to any hook.
The inline arrow function is the simplest, most readable approach. The closure captures mutateSelectedAgent and project.name which would need to be listed as useCallback dependencies anyway, meaning the callback would still be re-created whenever those change.
When you should use useCallback:

Passing a callback to a large list of memoized children (e.g., a virtualized list where each row is React.memo'd and receives the same handler).
When the callback is a dependency of useEffect or useMemo.
When profiling reveals unnecessary re-renders caused by unstable references.
In this component, adding useCallback would add complexity (dependency arrays, imports) without any measurable benefit. The inline handlers are the right choice.