fix(QUICStream): handle peers that start with zero stream credit

[lmvdz]

Problem

QUICStream's constructor eagerly primes every new stream with connection.conn.streamSend(streamId, new Uint8Array(0), false) to keep local stream state symmetric with closing behavior (src/QUICStream.ts around L280-310). When quiche returns `StreamLimit` on that prime call, the constructor throws `ErrorQUICStreamLimit`.

That throw leaves the system in a broken state:

1. The local stream ID allocator in QUICConnection.newStream has already consumed the ID.
2. Quiche has no record of the stream (it only records once real bytes flow).
3. The next `newStream('uni')` call then hits `ErrorQUICUndefinedBehaviour: We should never repeat streamIds when creating streams`.

The connection is effectively dead for outbound streams, permanently.

Where this matters

This bites any peer that advertises `initial_max_streams_uni: 0` (or an already-exhausted count) and uses `MAX_STREAMS` frames to grant credit post-handshake. That's how several production servers implement rate-limited / stake-weighted QoS.

Concrete case: Solana's Agave TPU-QUIC server. It advertises 0 initial uni streams to unstaked clients and drip-feeds `MAX_STREAMS` frames under a stake-weighted rate limiter. With the current `@matrixai/quic@2.0.9`, every `newStream('uni')` against an Agave TPU fails with `StreamLimit` before any bytes can be written. This affects ~80% of Solana mainnet leader slots.

Fix

Two small, narrowly-scoped changes in `QUICStream`:

1. `createQUICStream`: if the eager-prime throws `StreamLimit`, swallow it instead of propagating. The stream object is still constructed locally — the caller gets a live stream it can write to. Quiche's internal state isn't touched by a failed zero-length prime, so the stream ID remains free to use when `writableWrite` actually sends bytes.

2. `writableWrite`: bounded retry on `StreamLimit`. Up to 20 attempts at 50 ms intervals (≈1 s total budget). This gives the connection's receive loop time to process incoming `MAX_STREAMS` frames before we fail the caller. If credit doesn't arrive within the budget, the existing `ErrorQUICStreamInternal` path fires unchanged.

For peers that advertise non-zero initial credit, behavior is unchanged — the eager-prime succeeds on the first try and the retry loop never fires.

Verification

I'm building a Solana TPU client in TypeScript (lmvdz/tpu-client). Tested both of these scenarios:

• Local Agave (`solana-test-validator` 3.1.11): integration test submits a signed `SystemProgram::transfer` via TPU-QUIC and polls `getSignatureStatuses` until `processed`. Pre-fix: every attempt returns `StreamLimit` before any bytes leave the client. Post-fix: tx lands.
• Live mainnet-beta: 6-node comparative probe (3 Agave 3.1.13, 3 Frankendancer 0.820.30113) writing a 100-byte stub on a client-initiated uni stream. Pre-fix: 0/3 Agave sends succeeded, 3/3 Frankendancer. Post-fix: 2/3 Agave (1 was an unrelated network timeout on a non-leader), 3/3 Frankendancer.

Not included here

• No new tests added upstream here. Happy to add one that uses `initial_max_streams_uni: 0` on the server side + a synchronized `MAX_STREAMS` write, if that'd help land this. Flag if you'd like me to.
• I kept the eager-prime intact and just made the StreamLimit path non-fatal. Didn't want to restructure a hot path more than necessary. An alternative would be to drop the prime entirely for streams where the local peer knows it has no credit yet, but that's a bigger behavioral change.

Retaining behavior summary

Scenario	Pre-fix	Post-fix
Peer advertises adequate initial stream credit	✅ works	✅ works (unchanged)
Peer advertises 0 initial credit, grants via MAX_STREAMS fast	❌ eager-prime throws, connection dead	✅ retry loop bridges the gap
Peer never grants credit	❌ StreamLimit error	❌ StreamLimit error after ~1 s (same terminal state, just delayed)