[akasakariko]

Problem

Fixes #4246

In HTTP/1 dispatch, SendRequest can report readiness while a request is already queued or in flight, potentially causing a subsequent request to be canceled

Previously, the dispatch receiver signaled want whenever poll_recv() returned Pending
Because Pending can also occur when Tokio's cooperative budget is exhausted or a request is sent concurrently—not only when the queue is empty—this could restore readiness after the sender had already consumed it
Furthermore, withdrawing the signal on dequeue could invalidate readiness that the sender had already observed

Changes

• Grant readiness only once per receive cycle instead of re-signaling on Pending, and initialize the channel with one grant so the first request can be sent immediately
• Remove receiver-side readiness withdrawal and the separate buffered_once logic
• Preserve HTTP/2's unbounded dispatch behavior without changing public APIs or adding dependencies

Testing

• Extended h1_ready_in_flight to check both poll_ready() and is_ready() while a request is queued and in flight

• Verified that the False SendRequest readiness for HTTP/1 connections #4246 reproducer fails before the fix and passes afterward

• Passed cargo test --features full (328 passed, 10 ignored), Clippy, rustfmt, feature-powerset, MSRV, and semver checks

• The description, docs, and comments (words meant for humans) are written by a human, not by an LLM.