client: make BidiStream receive initialization cancellation-safe

[EffortlessSteven]

What this does

Cancelling the first BidiStream::message() while it waits for receive initialization could leave RecvState failed without an underlying error. Later reads then returned internal("stream in failed state") even if the server completed normally.

Fix: keep receive initialization inside RecvState while response headers and response-stream construction are pending. A cancelled message() call leaves initialization resumable by the next call, while real transport, deadline, and protocol failures remain terminal and sticky.

Verification

Check	Result
cancel before response headers	unpatched stream in failed state, patched yields the response message
cancel during Connect error-body parsing	unpatched stream in failed state, patched returns the server error
deadline during header wait	patched DeadlineExceeded stays sticky
transport failure	patched original Unavailable stays sticky
auto traits	Send / Sync / Unpin preserved
half-duplex sends before first read	preserved
cargo test -p connectrpc --all-features	clean
cargo test -p connectrpc --no-default-features	clean
cargo clippy -p connectrpc --all-features --all-targets -- -D warnings	clean
cargo +nightly-2026-02-27 fmt --all -- --check	clean
RUSTDOCFLAGS=-Dwarnings cargo doc -p connectrpc --all-features --no-deps	clean

Review map

• connectrpc/src/client/mod.rs: retain bidi receive initialization as AwaitingHeaders and Constructing; store terminal initialization errors as Failed(ConnectError).
• connectrpc/src/client/mod.rs tests: pin cancellation before headers, cancellation during Connect error-body parsing, sticky failures, auto traits, and half-duplex preservation.
• .changes/unreleased: document the user-visible cancellation-safety fix.

[EffortlessSteven]

Not intended for upstream yet.