Document downstream consumer delivery and reconnect semantics for WebSocket and MQTT event streams

[jillesvangurp]

Summary

A separate analytics consumer can be built now, but the hub should document the downstream-consumer contract more explicitly so reconnect, duplicate handling, and ordering assumptions are clear for WebSocket and MQTT stream consumers.

Scope

• document the expected delivery semantics for outbound WebSocket and MQTT event streams
• document reconnect expectations and likely duplicate or replay behavior
• clarify ordering assumptions, backpressure consequences, and consumer responsibilities
• align the docs with the actual runtime behavior and known limitations

Done when

• downstream consumers have one clear reference for delivery, ordering, reconnect, and duplicate-handling expectations
• analytics and integration projects can build against the stream contract without reverse-engineering behavior from code

[jillesvangurp]

Reviewing the April 1-2 changes against this issue, the runtime and docs now capture some of the needed behavior: queue drops, deduplication, batching, and slow-consumer consequences are documented more clearly after PRs #31, #32, #33, #34, and #35.

I am not closing this yet because there is still no single consumer-facing contract that tells downstream WebSocket and MQTT consumers what to assume about ordering, reconnect behavior, duplicate handling, and delivery semantics in one place.

I opened #39 to track that remaining documentation slice.

Relevant PRs: #31, #32, #33, #34, #35