Migrate the queryMembers and push preference request bodies to generated models

[gpunto]

Goal

Migrate the queryMembers and push-preference request bodies to their generated models.

Part of AND-1291

Implementation

• Replace the hand-written QueryMembersRequest with the generated QueryMembersPayload, and
  UpsertPushPreferencesRequest plus its UpstreamPushPreferenceInputDto and UpstreamChatPreferencesDto
  with the generated request, PushPreferenceInput and ChatPreferencesInput. The push-preference
  response was migrated earlier, so this finishes that endpoint.
• Add Member.toChannelMemberRequest() and replace ChatPreferences.toDto() with
  ChatPreferences.toChatPreferencesInput(), converting each toggle to its generated sealed type.
• Register the 17 sealed-class enum adapters the three new models declare. Moshi resolves an adapter for
  every declared property type when it builds the enclosing adapter, so a missing one fails at runtime
  rather than at compile time, even for properties that are always null.
• The DownstreamPushPreferenceDto and DownstreamChatPreferencesDto stay: they are still used by the
  user DTOs.

Notes

• members narrows from the full UpstreamMemberDto to ChannelMemberRequest, which drops nothing the
  endpoint reads: the handler only calls Members.HashUserIDs() to resolve a distinct channel. The role
  and custom data are still carried, since the domain member has them.
• PushPreferenceInput also declares call_level, feeds_level, feeds_preferences and user_id. The
  domain input types have no counterpart for any of them, so they are absent rather than defaulted.
• queryBannedUsers was in scope and is deferred: the generated QueryBannedUsersPayload has no
  counterpart for the four created_at_* filters the SDK sends. Go's payload embeds *types.BansPager
  which declares them, but the payload's OpenAPIInfo() hand-lists its properties and includes only
  limit and offset from that pager, so the spec under-declares fields the endpoint accepts. Adopting
  it would silently return unfiltered bans. Tracked in
  AND-1406.

Testing

• RequestBodiesAdapterTest pins the serialized body for the members query and for the three distinct
  push-preference shapes (chat_level, disabled_until, chat_preferences). The sort is a
  SortParamRequest literal rather than the output of the same conversion the payload uses.
• The MoshiChatApiTest cases for the six push-preference entry points now assert the generated request.
• Device-probed every entry point, since each emits a different body and one standing in for the rest
  would not cover the others. All six round-tripped: the levels and snooze timestamps came back as set,
  and the chat toggles came back populated, which is the field a previous slice silently dropped. Absent
  values are omitted from the body rather than sent as null. queryMembers went out as a URL query
  payload and returned the member with its role.
• Not routed in the E2E mock server, so no mock-server change is needed.

[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 the PR is bot-authored.
• An issue is linked (Linear ticket or GitHub issue), or the PR is bot-authored.

🎉 Great job! This PR is ready for review.

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-chat-android-client	6.06 MB	6.07 MB	0.02 MB	🟢
stream-chat-android-ui-components	11.36 MB	11.38 MB	0.02 MB	🟢
stream-chat-android-compose	12.84 MB	12.86 MB	0.02 MB	🟢

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud