Document AI client request configuration

[PVillarmarzo]

Summary

Documents the request configuration options available in RevealSdkClient.initialize() for the AI Client SDK.

Changes

• Added bearer-token authentication guidance using getBearerToken.
• Added onRequest guidance for custom or dynamic request headers.

Why

These APIs are already supported by @revealbi/api, but were not documented in the public AI Client documentation.

[brianlagunas]

These APIs weren't documented because they have not been finalized and verified

[zdrawku]

@brianlagunas I checked the SDK source and both options are implemented now and behave exactly as this PR describes.

• getBearerToken and onRequest are declared config options link
• getBearerToken is awaited per request and applied as Authorization: Bearer <token>: reveal-sdk-client.ts#L266-L293
• onRequest is registered as a request interceptor and interceptors are awaited, so async is supported: reveal-sdk-client.ts#L155-L167, http-client.ts#L94-L102
• The streaming note is accurate: streamPost runs interceptors once before fetch, when the SSE connection opens: http-client.ts#L356-L392

@PVillarmarzo, I have two review comments that I would want to be addressed before we merge this PR:

1. Mention the static bearerToken option (and setBearerToken() for refresh) next to getBearerToken — documenting only the dynamic form is a partial picture.
2. Consider a one-line note that onResponse / onError interceptors also exist, or explicitly scope them out.

[srodriguezinfragistics]

Just chiming in, maybe we can publish this as a preview topic, as we did with IMetadataStorageProvider ?

That way we have docs about them without committing to the current API, which I believe is what Brian was referring to when mentioning the API isn't finalized.

[PVillarmarzo]

Thanks all.

@zdrawku both points are addressed: the Preview topic now covers bearerToken, setBearerToken(), and getBearerToken, and also explicitly mentions onResponse and onError.

@srodriguezinfragistics I followed the Preview approach you suggested and moved the request configuration content into its own topic, using the same convention as IMetadataStorageProvider.

@brianlagunas this should address the original concern about documenting APIs that aren't finalized yet; the functionality is now clearly presented as Preview rather than as part of the stable API surface.

I also kept the wording intentionally conservative and limited it to behavior supported by the public API contract, rather than documenting implementation-specific interactions.

[srodriguezinfragistics]

Publishing this as preview looks good to me.