Add support for PredefinedFilters for QueryChannels

[VelikovPetar]

Goal

Add support for server-side PredefinedFilters to QueryChannels. Apps can now run a channel query by referencing a filter/sort registered on the backend (by name, plus interpolation values) instead of building the FilterObject/QuerySorter on the client. This lets product/backend tweak filtering rules without an app release.

You can check / update / create the predefined filters for the app "Stream Mobile SDK / Stream SDK - Android" - in the "Predefined Filters" section in the Beta Dashboard

Implementation

Public API

• QueryChannelsRequest gains predefinedFilter: String?, filterValues: Map<String, Any>?, sortValues: Map<String, Any>?. When predefinedFilter is set, the client-side filter/querySort are ignored by the backend.
• QueryChannelsResult is a new wrapper around ChatApi.queryChannels that exposes both channels and the backend-resolved PredefinedFilter (parsed name + FilterObject + QuerySorter<Channel>).
• ChannelListViewModel (Compose) and ChannelListViewModel (UI Components) get a new constructor / ChannelListViewModelFactory overload taking predefinedFilterName, filterValues, sortValues. In predefined mode, setFilters/setQuerySort are no-ops; channel search still narrows the displayed list.

State / offline architecture

• New QueryChannelsIdentifier sealed type (Standard / Predefined) is the canonical key used by LogicRegistry, StateRegistry, the listener, and the offline repository. A QueryChannelsRequest/QueryChannelsSpec resolves to one or the other depending on whether predefinedFilter is present.
• QueryChannelsSpec keeps its existing (filter, querySort) constructor (so JVM signatures stay stable) and adds predefinedFilterName/predefinedFilterValues/predefinedSortValues as vars. For predefined queries, those three form the row's stable identity; filter/querySort carry the currently resolved values.
• QueryChannelsMutableState starts predefined queries with placeholder filter/sort and applies the resolved spec via applyResolvedSpec(...) once the backend response arrives (or the row is rehydrated from disk).
• Internal ChannelListViewModel.QueryMode (Standard vs Predefined) drives the two flows — pagination, refresh, search, and filter-flow wiring branch on it.

Persistence

• QueryChannelsEntity gains predefinedFilterName/predefinedFilterValues/predefinedSortValues. QueryChannelsRepository.selectBy(identifier) replaces the previous filter-based lookup.
• Room DB version bumped to 104 (destructive migration, in line with the rest of the SDK).

Wire format

• FilterDomainMapping now supports a full round-trip (DTO ↔ domain) so the resolved predefined filter coming back from the server can be parsed into a FilterObject and stored.

Testing

• Unit tests added/updated across the new boundaries: QueryChannelsIdentifier derivation, MoshiChatApi, FilterDomainMapping (round trip), QuerySortByField round trip, DatabaseQueryChannelsRepository, QueryChannelsLogic / QueryChannelsDatabaseLogic / QueryChannelsListenerState, QueryChannelsMutableState, LogicRegistry, and both ChannelListViewModels.
• Both sample apps (Compose and UI Components) are wired to a backend-registered android_sample_filter so the feature can be exercised end-to-end on device.

[github-actions]

PR checklist ✅

All required conditions are satisfied:

• Title length is OK (or ignored by label).
• At least one pr: label exists.
• Sections ### Goal, ### Implementation, and ### Testing are filled (or ignored for dependabot PRs).

🎉 Great job! This PR is ready for review.

[github-actions]

DB Entities have been updated. Do we need to upgrade DB Version?
Modified Entities :

stream-chat-android-client/src/main/java/io/getstream/chat/android/client/internal/offline/repository/domain/queryChannels/internal/QueryChannelsEntity.kt

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-chat-android-client	5.82 MB	5.83 MB	0.01 MB	🟢
stream-chat-android-ui-components	11.02 MB	11.03 MB	0.01 MB	🟢
stream-chat-android-compose	12.37 MB	12.39 MB	0.02 MB	🟢

[gpunto]

LGTM!

[sonarqubecloud]

Quality Gate failed

Failed conditions
75.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud