feat: update to open api version 233.25.1

[oliverlaz]

Regenerates the client from the chat serverside spec at v233.25.1 (previously v233.9.1, #324).

Chat: member_custom_include

New request parameter that projects selected top-level keys of the message sender's channel-member custom data under member.custom (max 8 keys, 64 chars each). Added to:

• ChannelApi.getManyMessages
• ChatApi.getManyMessages
• ChatApi.getReplies
• ChatApi.queryChannels (QueryChannelsRequest)
• ChatApi.getOrCreateChannel / ChatApi.getOrCreateDistinctChannel (ChannelGetOrCreateRequest)
• MessageOptions

Response side: ChannelMemberPartialResponse.custom?: Record<string, any> carries the projected fields.

Video: encryption settings ⚠️ breaking

EncryptionSettings moves from a boolean toggle to a tri-state mode:

 interface EncryptionSettingsRequest {
-  enabled?: boolean;
+  mode?: 'available' | 'disabled' | 'auto-on';
 }

 interface EncryptionSettingsResponse {
-  enabled: boolean;
+  mode: 'available' | 'disabled' | 'auto-on';
 }

Migration for consumers: replace encryption: { enabled: true } with encryption: { mode: 'auto-on' } (or 'available' to allow but not force E2EE), and enabled: false with mode: 'disabled'. Reads of response.encryption.enabled become response.encryption.mode.

Nothing inside this repo referenced these fields, so build, typecheck and tests are unaffected — but it is a source-breaking change for SDK users. Titled feat: to match prior spec-update PRs (#324 also removed public methods under a plain feat:); flagging here so it can be re-scoped to feat!: if you'd rather cut 0.8.0 than 0.7.64.

Moderation

• New delete_user_messages action on SubmitActionRequest, with DeleteUserMessagesRequestPayload: delete_messages mode (soft | pruning | hard), optional channel_cid to scope to one channel, delete_reactions, entity_id / entity_type, reason.
• FilterConfigResponse.ai_image_taxonomy — available AI image moderation labels as an L1 → L2 map, reflecting the app's effective image taxonomy.
• MatchedContent.text.
• allowlist?: string[] on FloodConfig, FloodIdenticalRuleParameters and FloodSimilarRuleParameters.

Blocklists: server-side user context

user_id / user on CreateBlockListRequest and UpdateBlockListRequest; user_id on deleteBlockList.

Rate limits: Unity platform

unity request flag and unity?: Record<string, LimitInfoResponse> response field on CommonApi.getRateLimits and FeedsApi.getFeedsRateLimits.

Not included: importer external storage

The spec still exposes /api/v2/imports/v2/external-storage[/validate], so codegen re-added the four methods #324 removed as "decidedly not part of Stream's public API". They have been stripped again here, along with their models and decoder:

• deleteImporterExternalStorage, getImporterExternalStorage, upsertImporterExternalStorage, validateImporterExternalStorage
• GetExternalStorage{AWSS3,GCS,}Response, UpsertExternalStorage{AWSS3Request,GCSRequest,Request,Response}, ValidateExternalStorageResponse
• decoders.GetExternalStorageResponse

Worth noting this is now a recurring manual post-generation edit — every regeneration will reintroduce it until the endpoints are excluded from the spec or the generator.

Verification

• yarn build — passes
• tsc --noEmit — clean (exit 0)
• yarn lint — 0 errors
• yarn lint:gen — no reformatting needed
• yarn test — 143 passed / 6 failed / 19 skipped

The 6 failures (4× permissions and app settings API role tests, rate limit > should include rate limit in errors as well, webhooks > verify webhook - user.updated) reproduce identically on unmodified main, so they are pre-existing and environmental rather than caused by this change.

CI test-node is red for a pre-existing reason

All four test-node matrix jobs fail here on channel.test.ts:77:

FAIL __tests__/channel.test.ts > channel API > queryChannels
AssertionError: expected 1 to be greater than 1

This is not caused by this PR. The same assertion at the same line fails on unmodified main — see run 30007936823 for chore(main): release 0.7.63. The test.yml workflow has failed on 9 of the last 12 main runs, including the merges of both #324 and #325.

The test does an unfiltered client.chat.queryChannels() and asserts channels.length > 1, so it depends on ambient channel data in the shared test app rather than on anything it sets up itself. test-bun — which runs the same suite — passes, and CI's permissions/rate-limit/webhook tests pass here while failing locally, which is the signature of shared-app/env data dependence rather than a code defect.

Worth fixing separately (have the test create the channels it counts, or filter to its own fixtures); out of scope for a codegen update.