connect() returns Ok for a session that failed during the readiness wait

[kixelated]

Problem

Driver::wait_ready (rs/moq-net/src/session.rs) drives the session until the initial announce set lands, and discards the driver's own result while doing so:

let _ = self.poll(waiter);

If the session dies during that window (the announce stream fails to open, the peer's response is malformed, the transport closes), the driver finishes and drops the ConnectingProducer clones it owns. That resolves readiness, so Client::connect returns Ok((session, driver)) for a session that is already dead. The error isn't lost, it's cached on the driver and surfaces when the caller polls it, but connect() reporting success for a handshake that failed is misleading, and callers that spawn the driver and only watch Session::closed() see a connect that "succeeded" and then immediately closed.

Scope

Pre-existing, not a regression: moq-lite has used wait_ready this way since the initial-set wait was added, and before #2826 the moq-transport ALPN paths returned Ok without waiting at all. #2826 (MoQ Namespace Count) put the moq-transport paths on the same wait, which is what surfaced it in review.

Suggested fix

Make wait_ready return Result<(), Error> and propagate a driver completion that lands before readiness, then have Client::connect fail rather than hand back a dead pair. Worth regression tests for the three ways it can happen: a stream-open failure, a transport close mid-handshake, and a malformed response.

Found by the Codex adversarial review on #2826.

(written by Opus 5)