feat: add instance configuration service

[MartinCupela]

What

release-v10 could already register a setup function per entity — but only a function, and only
against four hardcoded keys. Anything that was just a value meant writing a function to go and set it.

This PR makes configuration values first-class: they can be registered declaratively, every key is
declared and type-checked, and every configurable object resolves its settings through one layered
pipeline with the server's say applied last.

The four ways to set configuration

Route	Scope	Use it for
Construction argument — new StreamChat(key, { notifications }), new MessageComposer({ config })	one instance	what you know at build time, for objects you build yourself
Declarative — client.config.set({ channel: { … } })	per entity type	the common case; reaches objects the SDK builds for you, including ones created later
Setup function — client.config.setSetupFunction('messageComposer', fn)	per entity type, but sees the instance	behaviour values can't express — middleware, comparators, conditional exceptions
Imperative — instance.updateConfig({ … }), and the setters that route through it	one instance	changes driven by app state after the fact

Plus one that isn't integrator's to set but participates: the server's configuration for the
channel — its type's settings, narrowed by that channel's own config_overrides where it has any.

Example of configuration API in use:

// declarative — applies to instances that exist and to any built later
client.config.set({
  channel: { messagePaginator: { pageSize: 50 }, typingEvents: { enabled: false } },
  messageComposer: { linkPreviews: { enabled: false } },
  client: { notifications: { durations: { error: 10_000 } } },
});

// setup function — a global default plus one conditional exception
client.config.setSetupFunction('messageComposer', ({ composer }) => {
  if (composer.threadId) composer.updateConfig({ text: { publishTypingEvents: false } });
});

client.config.reset() returns everything to its derived baseline.

The layers, and how they reconcile

For any one instance, later stages win:

#	Stage	Who set it	Example
1a	Class default	the SDK, for every instance of the class	every paginator starts at pageSize: 25
1b	Instance default	the SDK, for this particular object it built	a channel's pinned list is wired differently from its main list, though both are MessagePaginators
2	Declarative	you, per entity type	client.config.set({ channel: { … } })
3	Construction argument	you, for one instance	new MessageComposer({ config })
4	Setup function	you, per entity type, with the instance in hand	client.config.setSetupFunction(key, fn)
5	Imperative	you, for one instance, at any time	instance.updateConfig({ … })
6	Server	the server, per channel	narrows only; can never be widened from the client

The one non-obvious part is why 1b and 3 are separate when both arrive through a constructor. It's who
passed the argument. When the SDK builds a paginator it fills in a page size, a throttle and a
cursor — if those counted as integrator's arguments they would outrank stage 2, and no client.config.set()
could ever change them. So the SDK's own values sit at 1b, below integrator's registration; only arguments integrators
actually passed sit at 3, above it.

Three properties of this that are load-bearing:

• Re-resolved, not accumulated. Every layer is kept separately and the whole order replays whenever
  any of them changes. So applying the server's restrictions is idempotent, and stage 6 narrowing a field
  never destroys the request underneath it — if the server later relents, the request is honoured.
• Server authority is last on every route. Declarative, setup function or updateConfig — all three
  have the server's restrictions re-asserted over the result. Nothing above can widen past them.
• Booleans are ANDed at stage 6. Either side may switch a feature off; neither may widen. undefined
  from the server means "no opinion", not "no", so the request stands.

The consequence worth knowing: instance.config is the resulting answer. It should be read instead of the raw
server flag — channel.serverConfig?.uploads - which gives us only the server's half.

Why

Setting a page size used to require writing a function:

// before
client.instanceConfigurationService.setSetupFunctions({
  Channel: ({ channel }) => {
    channel.messagePaginator.updateConfig({ pageSize: 50 });
  },
});

// now
client.config.set({ channel: { messagePaginator: { pageSize: 50 } } });

Four things were wrong with the old version:

1. A function was the only way in. There was no way to register a plain value.
2. Only four classes were supported — Channel, MessageComposer, StreamChat, Thread. Paginators,
   the notification manager, the reminder manager and the delivery reporter had no way in at all.
3. No way to undo it. Nothing tracked where a value came from, so nothing could put an instance back
   to a known state.
4. Server settings were not included. If the server disabled uploads, the code had to check that
   separately and combine it in multiple places. Most code didn't, so a UI would offer a feature the SDK then
   refused.

Where it lives

Two objects, and neither holds what the other holds:

	InstanceConfigurationRegistry (client.config)	ConfigController (per instance)
Holds	what you asked for (stages 2 and 4)	what one instance ended up with
Count	one per client	one per configurable instance
Knows defaults	no	yes, and freezes them

Every configurable class exposes the same shape: configState (a StateStore), config,
updateConfig(), initializeConfig(). Thread was the last one resolving configuration by hand and now
goes through ConfigController too, so there are no exceptions left.

The key space is closed. InstanceConfigTree and InstanceSetupFunctionArgs are type aliases, not
interfaces, so a key can be neither misspelled into existence nor added by module augmentation:

client.config.setConfig('myWidget', { pollIntervalMs: 10_000 }); // ✗ does not compile
client.config.setSetupFunction('cahnnel', fn); // ✗ does not compile

A class an integrator owns configures itself — a constructor argument, a setter, its own registry.
Routing it through client.config would put a value the SDK can neither type nor apply into a tree whose
only reader is the SDK.

The machinery is internal too. ConfigController (which resolves a configuration) and
applyInstanceConfiguration (which subscribes an instance to a key) are both unexported: every
configurable class is one this package constructs, so neither has a caller outside it.

⚠️ Breaking changes

Details in v9-to-v10-migration-guide-other.md and …-type-renames.md.

Two that produce no compile error

Uploads to storage outside Stream must now be declared. A custom doUploadRequest used to be taken
as proof of that, which was wrong — many still post to Stream. Without the flag, uploads are refused for
users lacking the upload-file capability, and the attachment button disappears:

attachments: { doUploadRequest: myUpload, customCdn: true }

Link previews now default to on. The old default of off overrode apps that had enabled enrichment
server-side. Turning them off is now explicit:

client.config.set({ messageComposer: { linkPreviews: { enabled: false } } });

Renames — all caught by the compiler

channel.getConfig()          →  channel.serverConfig         // a getter; drop the ()
client.configs               →  client.channelServerConfigs  // same cid keys, clearer name
ChannelInstanceConfig        →  ChannelConfig
ThreadInstanceConfig         →  ThreadConfig
InstanceConfigurationService →  InstanceConfigurationRegistry

serverConfig returns what getConfig() did. channel.config is a different thing: the resolved
value, with six server flags already combined with locally registered settings — that is the one to read
when checking whether a feature is on.

serverConfig answers for this channel, not for its type. Most of ChannelConfigWithInfo is a
channel-type setting, but a channel's own config_overrides narrow uploads, url_enrichment,
typing_events, replies, quotes, reactions, shared_locations, max_message_length, commands
and user_message_reminders for that channel alone — and this SDK is one of the things that can set them
(client.channel(type, id, { config_overrides }) sends them on query/watch; channel.update() and
updatePartial() reach the same state). So the cache behind the getter is keyed by cid: v9's
client.configs key space, under a name that says whose configuration it holds now that client.config
is the integrator's.

It is undefined until the channel has been queried or watched, as in v9. There is deliberately no
type-level fallback — the only value available to seed one with is a sibling channel's effective config,
overrides included, which is the leak the cid keying exists to prevent. channel.config covers that
window with its defaults, which is another reason to read it rather than the raw flag.

Note for tests: serverConfig is a getter, so vi.spyOn(channel, 'getConfig') has no direct equivalent.
A mocked query response has to carry a cid matching the channel under test, or its config lands under a
different key.

Smaller things

• MessageComposerConfig gains polls; AttachmentManagerConfig gains enabled and customCdn. All
  have defaults, so only code that types a variable as the complete config object is affected.
• Removed from the client: setInstanceConfigurationFunction, instanceConfigurationService and
  configsStore (all RC-line only). configs is renamed to channelServerConfigs, not removed — the
  cid key space is unchanged, so a v9 client.configs[cid] lookup translates directly. Prefer
  channel.serverConfig over either.
• Bug fix, no action required: setters no longer skip a write when the server is masking the field, which
  used to let a stale earlier request win once the server allowed it again.

RC-line only

None of these ever shipped in v9, so they are listed for anyone tracking release-v10 rather than as
migration steps.

• channel.config carries only the channel's own fields. The channel slice can also carry
  messagePaginator, pinnedMessagesPaginator and messageOperations — those still work as scoped
  overrides for the objects the channel owns, they are just no longer copied onto channel.config as
  well, where nothing read them and ChannelConfig never declared them. Read
  channel.messagePaginator.config instead. Side benefit: registering a scoped option no longer notifies
  channel.configState subscribers. Silent — the old read returns undefined.
• The key space is closed. setConfig('anything', …) and setSetupFunction('anything', fn) no longer
  compile, and the two key interfaces are type aliases so augmentation cannot add one either.
  applyInstanceConfiguration, ConfigController and ConfigControllerOptions are no longer exported.
• liveLocationManager.dispose() is new, and needs calling. unregisterSubscriptions() is
  ref-counted and no longer releases the configuration subscription — it never should have, since with two
  callers sharing a manager the first to leave stopped a still-live instance from tracking
  client.config. Until dispose() runs, the configuration registry holds a handle to the manager.
  Nothing fails to compile. SearchController already worked this way.
• Thread gains updateConfig() and resolves through ConfigController like every other entity.
  Additive.

Review guidance

• src/configuration/ConfigController.ts — the layering itself (orderedLayers, resolve). Start here.
• src/configuration/utils/serverAuthority.ts — stage 6: the AND rule and the upper-bound rule.
• src/channel.ts — the most involved consumer: controller, server restrictions, and the
  subscription that re-derives when the server's answer arrives after construction.
• src/configuration/shape.ts is 644 lines of field descriptions, not logic — skim it.

Docs

• docs/instance-configuration.md — full reference: the stages, the registry/resolver split, server
  authority, custom keys, resetting.
• Three v9→v10 migration guides updated, with a mechanical checklist.

[stream-ci-bot]

🎉 This PR is included in version 10.0.0-rc.7 🎉

The release is available on:

• GitHub release
• npm package (@rc dist-tag)

Your semantic-release bot 📦🚀