perf: avoid relocking response stream references

[brentechols]

• The description, docs, and comments (words meant for humans) are written by a human, not by an LLM. (https://seanmonstar.com/micro/20260729-i-want-your-own-words/)

Summary

• create the request stream, response handle, and response-body handle while the stream store is already locked
• transfer the precreated body handle into RecvStream instead of cloning at response completion
• read the stream ID from its stable key without locking shared stream state

Motivation

A normal client request currently reacquires the connection-wide stream mutex to clone its response handle after insertion, then reacquires it at response completion to clone the body handle. This creates both handles during the existing locked stream insertion and moves the body handle on completion.

ResponseFuture retains its original handle, preserving post-completion informational-response and push-promise access. Reference drops keep their existing locking behavior.

Scope

This is independent of the receive-side send-buffer lock patch and is based directly on master. Existing fixtures now cover ordinary and pushed response IDs after manual completion, plus post-completion push_promises() and poll_informational() behavior.

Performance

Seven rotated 100,000-request pairs produced these medians:

Server runtime	master	this PR	elapsed change
current-thread	414 ms	412 ms	-0.5%
4-worker	467 ms	455 ms	-2.6%

Each variant won four of seven paired runs, so the current-thread result is effectively neutral and the multi-thread result is a small, noisy improvement. The 1 GiB sustained-transfer case showed no reliable gain, which is expected for a change aimed at request/reference churn.

Validation

• cargo fmt --all -- --check
• cargo check --all-targets --offline
• cargo test -p h2 --lib --no-default-features --offline (428 passed, 1 ignored)
• cargo test -p h2-tests --offline (complete integration suite, including the 5,000-connection hammer test)