Baozi WebSocketConfig (watchTimeoutMs) not wired into core's BaoziExchangeOptions at all

[realfishsam]

Gap

Core's changelog documents a watchTimeoutMs WebSocket config option added to every exchange, explicitly naming Baozi among the affected venues. But BaoziExchangeOptions has no websocket field at all, so the option can never be set — even by a core consumer bypassing both SDKs entirely. This differs from the already-filed pattern for Kalshi/Polymarket/Opinion/Probable/Limitless (#1053/#1052/#973/#972/#1105), where the option is wired into the venue's core ExchangeOptions and the gap is purely "SDK doesn't forward it." For Baozi, the wiring is missing at the core constructor level too.

Core

• core/src/exchanges/baozi/websocket.ts:18-21 — defines BaoziWebSocketConfig { watchTimeoutMs?: number }, used at websocket.ts:90 to bound watchOrderBook's wait.
• core/src/exchanges/baozi/index.ts:48-51 (BaoziExchangeOptions) — has only credentials and rpcUrl, no websocket field.
• core/src/exchanges/baozi/index.ts:420 — always constructs new BaoziWebSocket() with defaults, so the config can never be set even from within core itself.

TypeScript SDK

N/A at the SDK layer — nothing in core to pass through. sdks/typescript/pmxt/client.ts:3382-3386's Baozi constructor takes generic ExchangeOptions with no websocket passthrough.

Python SDK

N/A at the SDK layer — same. sdks/python/pmxt/_exchanges.py:235-260's Baozi.__init__ only accepts private_key, base_url, auto_start_server, pmxt_api_key.

Evidence

core/src/exchanges/baozi/index.ts:48-51 (options shape) vs. websocket.ts:18-21,90 (the config the WS client actually accepts) — direct comparison confirms the option can never be threaded through.

Impact

The documented watchTimeoutMs feature is completely dead for Baozi specifically — neither a direct core consumer nor either SDK user can configure how long watchOrderBook waits before timing out for this venue.

---

Found by automated Core-to-SDK surface coverage audit