fix: release request tracking when resolver ends early

[Streetblock]

Dropping a server RequestResolver, cancelling resolve_request() while waiting for headers, or returning an error before constructing a RequestStream leaves the stream ID in Connection::ongoing_streams. The completion guard is currently created only after the initial HEADERS frame has been read and decoded.

Create the existing RequestEnd guard when the resolver is created and move it into RequestStream on successful resolution. This preserves the existing split-stream lifetime behavior and also notifies the connection when resolution ends early. Header timeout policy remains with the caller; the method documentation now states that explicitly.

Regression tests use a local QUIC peer sending an incomplete HEADERS frame and cover timeout cancellation, dropping an unpolled resolver, and an incomplete stream ending before header resolution. They assert that the connection removes the ongoing stream after processing completion notifications.

Validation:

• The timeout-cancellation regression fails on upstream 1f3d529 with cancelled resolver retained in ongoing_streams and passes with this fix.
• cargo test -p h3 --all-features
• cargo fmt --all -- --check

This fixes resolver lifecycle accounting; it does not add a runtime-specific timer or set a server timeout policy.

[Ruben2424]

lgtm, thanks