fix(search): search results never show lists #8940

Summary

The Lists row in search results is built to the design (#8540) but never appears in the app, because the list search almost never finds a list.

Environment

• feat/8198-lists-entry-surfaces at 8303733; the search path is unchanged from main, where it behaves the same
• iPhone 16 Pro simulator, staging, signed in

Steps to Reproduce

1. Open Search and type the name of a public list, or of one of your own lists (a renamed default list works).
2. Read the All tab, then switch the filter to Lists.

Actual Result

People, Tags and Videos render; there is no Lists row. The Lists filter shows the empty state.

Expected Result

The Lists row from the design (Figma node 11177-208723): one video-list card beside one people-list card, and the full grid on the Lists filter.

Root causes

1. The relay window is 50 events, and they are placeholders. CuratedListRepository._queryListsFromRelays asks for the newest 50 kind-30005 events (Filter(kinds: [30005], limit: 50)) and filters them by name, description and tags on the device. On the production relay the newest 2,000 kind-30005 events span five days: 1,967 are the auto-created my_vine_list ("My List") placeholder, 26 contain any video, 34 carry a non-default name. Pages sampled back to 2026-08-18 hold the same 1–2% share. A 50-event window is therefore all placeholders whatever the query. Staging is thinner but the same shape (834 of 2,000 placeholders).
2. The user's own lists are not in the local pool. searchAllLists seeds from searchLists, which reads the repository's _subscribedLists; those are bridged from CuratedListService.subscribedLists, which holds only lists the user subscribed to. CuratedListService.myLists is never included, so the user's own lists cannot match either.
3. People-list search is compiled out. ListSearchBloc queries kind 30000 only when FeatureFlag.profileListFeatures is on, and no build sets FF_PROFILE_LIST_FEATURES. The flag decision is task(lists): decide the fate of the profileListFeatures flag #8939. Even with it on, PeopleListsRepositoryImpl._queryPublicLists uses the same newest-50 window, and on production the newest 2,000 kind-30000 events are 1,044 dm-contacts sets and 660 block sets.
4. There is no server-side search to lean on. Funnelcake exposes searchProfiles, searchHashtags and searchVideos only. The relay advertises NIP-50, but a search filter returns matches only for video events (kind 34236 "coffee" → 3 hits); kinds 30005, 30000 and 0 return nothing. Backend request: divinevideo/divine-funnelcake#1228.

Explore → Lists still shows lists because CuratedListRelayGateway.streamPublicListsFromRelays reads from every connected relay, including the NIP-65-discovered ones, and sorts by video count, so a handful of real lists survive. Search runs the same fetch capped at 50 with a text filter on top.

Proposed fix (mobile)

• Include the public entries of CuratedListService.myLists alongside subscribed lists in the local pool the bridge pushes into the repository.
• Use the discovery pool (streamPublicListsFromRelays for kind 30005, discoverPublicLists for kind 30000: multi-relay, item-bearing lists only, sorted by video count) as the relay candidate set for the text filter instead of a fresh newest-50 query. This finds what Explore can show and nothing more, which is the honest ceiling until the backend can search lists.
• Once divinevideo/divine-funnelcake#1228 lands, pass search: query in the relay filter (NostrClient.searchEvents already supports NIP-50) and drop the client-side filtering.
• Gate the people-list stream per task(lists): decide the fate of the profileListFeatures flag #8939.

Not a fix: paging the relay backwards with until until a match budget is met. At 1–2% density that is thousands of events per keystroke.

Also seen, not fixed here: streamPublicListsFromRelays deduplicates by d tag alone, so every user's my_vine_list collapses into one entry across authors. Harmless while those lists are empty; a renamed default list that has videos will lose to another user's later placeholder.

Regression?

No. The search path predates #8540. The row is new to the design; the data source was always empty in practice.

Evidence

Relay probes on 2026-09-08:

nak req -k 30005 --limit 2000 wss://relay.divine.video      # 5-day span, 1,967 x my_vine_list, 26 with items
nak req -k 30005 --search Divines wss://relay.divine.video  # 0 events
nak req -k 30000 --search Divines wss://relay.divine.video  # 0 events
nak req -k 0 --search divines wss://relay.divine.video      # 0 events (profiles are searchable via REST, not NIP-50)
nak req -k 34236 --search coffee wss://relay.divine.video   # 3 events