Expose one fail-closed public market event stream for local orderbook reconstruction #109

Problem

A consumer that maintains an executable local orderbook needs the initial BookUpdate snapshot and every subsequent PriceChange in one ordered stream.

The unauthenticated Client currently exposes separate typed methods (subscribe_orderbook, subscribe_prices, subscribe_last_trade_price). Each calls SubscriptionManager::subscribe_market, which:

1. increments per-asset refcounts;
2. sends the server subscription;
3. only then creates its broadcast receiver.

This creates several fail-closed gaps:

• an immediate initial snapshot can arrive before the receiver exists;
• separately-created snapshot/delta receivers can be selected in a different order for equal timestamps;
• RecvError::Lagged is logged and then continued, so a consumer silently retains a stale book;
• if connection.send fails after refcounts are incremented, the increment is not rolled back;
• malformed public frames (for example an unknown price-change side) are dropped before typed consumers can fail closed.

These semantics are unchanged in current 0.7.0 and pinned 0.6.0-canary.1.

Requested API/behavior

Please expose an unauthenticated equivalent of subscribe_user_events, e.g.

pub fn subscribe_market_events(
    &self,
    asset_ids: Vec<U256>,
) -> Result<impl Stream<Item = Result<WsMessage>>>;

with these guarantees:

• one receiver is registered before the subscription request is sent;
• Book, PriceChange, LastTradePrice, and other market events preserve connection order in the same stream;
• broadcast lag yields an error/terminal gap instead of silently continuing (or provide an explicit fail-closed option);
• send/setup failures roll back refcounts and active-subscription state;
• malformed provider frames surface as an error or raw/unknown item rather than disappearing.

This blocks safe token-scoped book maintenance in PMKit: batched PriceChange entries can contain both complementary outcome token IDs, and merging separate typed streams cannot prove no snapshot/delta was missed or reordered.