quic: do not destroy incoming streams that have a consumer - #65335

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

• an onstream callback (any negotiated protocol), or
• session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

• Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
• The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
• This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
• The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.