Stream frames bypass the bounded queue under WebAssembly

[Platonenkov]

Under WebAssembly, stream frames bypass the bounded queue entirely, so nothing limits the backlog and nothing counts what is lost.

What happens

Connection.EnqueueStreamMessage (Xrpl/Client/connection.cs):

private void EnqueueStreamMessage(byte[] frame)
{
    if (OperatingSystem.IsBrowser())
    {
        _ = ProcessStreamMessageFireAndForgetAsync(frame);   // straight to a handler, no queue
    }
    else
    {
        channel.Writer.TryWrite(frame);
    }
}

Consequences in a browser:

• ConnectionOptions.StreamMessageQueueCapacity does nothing. The queue is created — StartMessageProcessor runs regardless of platform — but never written to, so its reader idles.
• DroppedStreamMessages stays at zero however far handlers fall behind, because nothing is ever evicted. The observability added in Обработчик потока выполняется внутри приёмного цикла: медленный подписчик останавливает всё соединение #105 is absent exactly where it is hardest to observe anything.
• The backlog is bounded by memory alone. One in-flight task per frame, with no ceiling: a handler slower than message arrival accumulates them until something gives.
• Ordering is not guaranteed. The non-browser path sets SingleReader = true and processes frames one at a time; fire-and-forget dispatches concurrently, so handlers can observe events out of order.

Why it was not simply changed

The comment on StartMessageProcessor says the channel exists for this environment:

Uses Channel<T> for true async support in WebAssembly single-threaded environment.

So the bypass reads more like a leftover than a decision — but that cannot be settled by reading. WASM is single-threaded, Task.Run there is cooperative rather than parallel, and whether the background reader gets scheduled the way the non-browser path assumes needs checking in a real browser. Nothing in this repository can run that check: there are no WASM tests, only the Blazor-WebAssembly demo project.

Changing stream dispatch blind, inside a PR about observability, was the wrong trade — so #105 documented the limitation on DroppedStreamMessages, on StreamMessageQueueCapacity, on the interface member and in CHANGES.md, and left the behaviour alone.

What this issue is for

Decide whether browser frames should go through the same bounded queue, and verify it where it actually runs:

1. Establish, in Tests/TestsClients/Blazor-WebAssembly, whether the channel reader is scheduled reliably under WASM — that is the question the bypass exists to dodge, and everything else follows from the answer.
2. If yes: delete the browser branch, so capacity, eviction counting and single-reader ordering apply everywhere, and the two paths stop diverging.
3. If no: keep the bypass but bound it — a semaphore or an explicit in-flight cap — and count what it discards, so the counter means the same thing on both platforms.

Either way the goal is that StreamMessageQueueCapacity and DroppedStreamMessages describe reality on every target, rather than on all but one.

Found by review of #109.

[Platonenkov]

Закрыто PR #111 (0821c5d) — Closes в теле не стоял, поэтому issue пережил слияние.

EnqueueStreamMessage больше не ветвится по OperatingSystem.IsBrowser(): путь один для всех платформ, так что StreamMessageQueueCapacity, учёт вытеснения и порядок от единственного читателя действуют и в браузере.

Обход убран, а не ограничен, потому что замер это подтвердил. Blazor-демо против mainnet: через очередь 1 004 транзакции за 52 с (19.2 tx/s, 13 леджеров), без ошибок в консоли, метки времени по порядку — против 462 за 33 с (13.9 tx/s) на обходе. Очередь для этой среды изначально и делалась: в StartMessageProcessor так и написано — «true async support in WebAssembly single-threaded environment».

Остаток, который PR не закрывал и не претендовал закрыть, живёт отдельно в #113: кадры, пришедшие до запуска процессора, всё ещё идут мимо очереди — теперь это видно через новый счётчик FallbackDispatchedStreamMessages.