task(lists): decide the fate of the profileListFeatures flag #8939

Description

Decide whether FeatureFlag.profileListFeatures keeps gating people-list surfaces or retires. The flag defaults off (FF_PROFILE_LIST_FEATURES, which no build configuration sets), is user-visible in Settings, and today gates exactly three surfaces, each layered on the master switch FeatureFlag.curatedLists (default on):

• "Add to list" in another person's profile more-sheet (lib/screens/other_profile_screen.dart)
• "Add to list" on user tiles in search results and follow lists (lib/screens/search_results/widgets/search_user_tile.dart, lib/widgets/user_profile_tile.dart)
• People-list cards in search results (ListSearchBloc.peopleListSearchEnabled, wired in lib/screens/search_results/view/search_results_page.dart)

Everything else about people lists is already general availability because curatedLists defaults on: creating people lists from your own profile, the people column of the profile Lists tab, the people column of the Explore → Lists discovery gallery (#8540), and opening any public people list read-only at /people-lists/:listId?owner=.

Context

#8198 already asks for "an early decision on whether that flag still has a reason to exist". #8540 rebuilt the entry surfaces to the approved design, and that design shows people-list cards in search results (Figma node 11177-208723), so the search row is now the only browsing surface that behaves as if people lists were still experimental. #8540 deliberately changes no gate; the presentation is done and this decision is what remains.

People-list search and discovery currently request only the newest 50 kind-30000 events. Most recent events are machinery lists such as DM contacts and block sets, so enabling the search row without widening that candidate window would expose the same empty-results failure fixed for video lists in #8940.

Options

1. Retire the flag. The three surfaces become general availability; delete the flag and its build define.
2. Keep it as the "authoring from other people's profiles" flag. The two add-to-list affordances stay behind it; the search results row moves to curatedLists like every other browsing surface.
3. Keep people lists experimental as a whole. Also gate the people column of the Explore gallery and of the profile Lists tab on it, since both are ungated today.

Acceptance Criteria

• Product owner picks an option and records it on this issue.
• The gates are updated to match in one PR, including search_results_page.dart.
• Before people-list search or discovery ships, raise their relay candidate window from 50 to the shared list-discovery window and cover the requested Filter.limit plus machinery-list filtering with repository tests.
• The description of the flag in lib/features/feature_flags/models/feature_flag.dart matches what it gates, or the flag is deleted together with FF_PROFILE_LIST_FEATURES in build_configuration.dart.

Testing

Widget tests for every touched gate, repository tests for the relay candidate window and machinery-list filtering, plus an on-device pass over search results, the other-profile sheet, user tiles, Explore → Lists and the profile Lists tab with the flag on and off.