fix(transport/websocket): refuse reconnect on evicted session instead of silently spawning new mux (fixes #354)

[Kiryuumaru]

Summary

Fixes #354.

WebSocketMuxListener.HandleAsync's ChannelClosedException catch (added by #279 for the eviction race) fell through to the fresh-session creation branch. This silently bound the reconnecting client's pair to a brand-new mux with a brand-new SessionId, causing the client's reconnect handshake to fault terminally with SessionMismatch — the exact defect #236 fixed and #279 unintentionally re-surfaced.

Trace

1. Mux X is active. _sessions[X] = entry.
2. Client reconnect Updated CICD #1 → HandleAsync(sessionId=X) → WriteAsync(pair1) succeeds (channel cap 1).
3. Mux X has not yet consumed pair1 when reconnect Added ARM64 CPU architecture support #2 arrives → WriteAsync(pair2) blocks (channel full).
4. Mux X's transport faults → Disconnected → evictHandler → TryComplete() on the channel.
5. Blocked WriteAsync throws ChannelClosedException.
6. Pre-fix: catch falls through, creates a new mux Y with SessionId = Y ≠ X, wires pair2 into Y's StreamFactory. Client's handshake then claims session X against mux Y → MultiplexerException(SessionMismatch) → client's mux is poisoned for life.

Fix

Mirror the unknown-session branch in the ChannelClosedException catch:

catch (ChannelClosedException)
{
    try
    {
        await webSocket.CloseOutputAsync(
            WebSocketCloseStatus.PolicyViolation,
            "Session has been evicted.",
            cancellationToken).ConfigureAwait(false);
    }
    catch { /* peer may be gone */ }
    try { await pair.DisposeAsync().ConfigureAwait(false); } catch { }
    return;
}

The client's next reconnect attempt will observe the session is truly gone and can fall back to a fresh sessionId = null connection (or surface the eviction to the application).

Tests

New: tests/NetConduit.Transport.WebSocket.IntegrationTests/Issue354ChannelClosedReconnectTests.cs

ReconnectBlockedOnFullChannel_SessionEvicted_RefusesInsteadOfNewMux:

1. Spins up a Kestrel WebSocket endpoint.
2. Opens a first WS, hands it into the listener as a new session; no consumer drains the mux so its bounded ConnectionChannel stays full.
3. Opens a second WS, calls HandleAsync(sessionId=X); blocks on WriteAsync.
4. Calls listener.RemoveSession(X) to evict the session, completing the channel writer.
5. Asserts HandleAsync#2 returns cleanly within 5s, the client observes a WebSocketCloseStatus.PolicyViolation close frame, and the internal _sessions dictionary is empty (no orphan mux Y was registered).

Verification:

• Without the fix: test fails with TimeoutException at the 5s WaitAsync — HandleAsync#2 is hanging inside the spawned mux Y's completion.Task.WaitAsync.
• With the fix: passes (~3.6s).

Full NetConduit.Transport.WebSocket.IntegrationTests suite: 18/18 pass.
Full solution build (net8/9/10): clean.

Related

• WebSocketMuxListener.HandleAsync silently creates a new mux for unknown sessionIds — client fails with SessionMismatch, server leaks one mux per stale reconnect #236 — original fix for unknown-sessionId fresh-mux silent spinup. This PR re-establishes the same refusal semantics on the eviction-race path.
• WebSocketMuxListener._sessions accumulates SessionEntry records forever — no subscription to mux.Disconnected/Closed, only manual RemoveSession() or full listener DisposeAsync() cleans up; long-lived listeners leak unbounded memory, and any peer presenting a dead-session GUID is routed to the disposed mux's stale Channel<CompletionStreamPair>, the pair is never consumed, HandleAsync hangs forever #279 — introduced the ChannelClosedException catch. Right intent (don't crash with the exception) but wrong recovery (fall through instead of refuse).
• fix(transport/websocket): always signal completion in CompletionStreamPair.DisposeAsync (fixes #353) #359 — sibling fix in the same file for WebSocketMuxListener.CompletionStreamPair.DisposeAsync skips completion.TrySetResult on inner.DisposeAsync throw — HandleAsync hangs until request cancellation #353.