Feature Flags Large List UI support

[danoswaltCL]

(this is generated w/ help from Claude based on the expectations I've given it, super detailed so copilot or other models can have the correct context for the change)

Feature flag detail & list operations remain performant with large (~20k) lists

Context

Feature flags whose inclusion/exclusion lists contain tens of thousands of members previously made the detail page, list edits, and enable/disable toggles slow or unusable. This branch makes those paths lightweight. This story validates the behavior and guards against regressions.

Test data / preconditions

• A feature flag (FLAG-BIG) with one inclusion list and one exclusion list, each with ~20,000 individual members.
• A feature flag (FLAG-SMALL) with small lists (a few members each) for baseline/parity checks.
• A flag with a segment-type list and a group-type list (to cover all list types).
• Browser devtools open (Network tab) for payload/timing checks.

---

AC1 — Detail page loads quickly for large lists

• Opening FLAG-BIG's detail page loads within a few seconds (no timeout, no visible hang).
• The GET /flags/:id response does not contain the full member arrays for the lists (it returns member counts only).
• Each list row shows the correct member count (e.g., "20000 Values").

AC2 — CRUD on lists is quick

• Create: Adding a new list (individual/group/segment) completes in a few seconds and the new row appears with the correct count.
• Read (edit open): Opening Edit on FLAG-BIG's 20k list loads the members into the form (via GET /segments/:id/members) and is usable; the form is populated before it can be submitted.
• Update: Removing one member from FLAG-BIG's 20k list and saving completes quickly (comparable to creating a list — not dramatically slower) and the count updates to 19,999.
• Delete: Deleting a list completes quickly and the row disappears.

AC3 — No duplicate requests / server overload

• In the Add or Edit list modal, clicking the primary (Add/Update) button disables it while the request is in flight, and only one request is sent (verify in Network tab — no duplicates from rapid clicking).
• This holds for feature-flag lists, experiment lists, and standalone segment lists (same modal).
• On a failed save, the button re-enables so the user can retry.

AC4 — Enable/disable is lightweight

• Toggling an inclusion list enabled/disabled on FLAG-BIG (and confirming) sends a small PATCH /flags/inclusionList/:id/status carrying only the enabled flag — it does not re-send the ~20k members.
• The toggle state and behavior update correctly.
• The list's members are unchanged afterward (reopen edit to confirm the 20k members are intact).

AC5 — UI parity (only the tooltip changes)

• The lists table looks and behaves identically to dev except the hover tooltip that previewed the first 10 values on the "Values" column is removed.
• List type, count text, name/description, the enable toggle (inclusions), and edit/delete actions all render and work as before.
• Exporting lists (include/exclude) still produces complete member data.

AC6 — Error scenarios covered

• When the member fetch (GET /segments/:id/members) fails, an error notification is shown and the modal closes — the user cannot save a list from a partially-loaded state (no accidental member loss).
• Toggling status or updating a list that no longer exists returns a clear error (not a silent success).
• Requesting a non-existent segment's members returns 404.

AC7 — Automated tests pass

• yarn backend test (unit + integration) passes.
• New backend methods are covered: findOneForDetails, updateListStatus (incl. not-found), getSegmentByIdWithMembers, the single-DELETE-by-segmentId teardown, and the new controller routes.

AC8 — Isolation / no regressions

• FeatureFlagService.findOne is unchanged vs base (full-member callers like design/list export still get members).
• Changes are limited to feature-flag, segment, shared list-modal/table, and the experiment store's loading flag; no unrelated files modified.
• Regression sweep: create/edit/delete/enable/disable on small lists behaves identically to dev; experiment and standalone-segment create/edit still work.

---

Out of scope / known limitations

(do not fail the story for these)

• Experiment detail and standalone segment detail/list pages still eager-load full members — they were not part of this change and remain as on dev (a separate optimization).
• Editing a list is still a full replace (the whole member list is re-sent and rewritten); this branch only makes the teardown/load cheap, not incremental.
• The exclusion list status-toggle code path exists but is unused (exclusion lists have no enable toggle in the UI) — dead code, not a defect.
• Frontend ngrx changes (reducers/selectors/modal wiring) are not covered by automated tests (no pre-existing specs for these components); verify manually per AC3.