perf: defer send buffer locking while receiving

[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

• avoid taking the outbound frame-buffer mutex for every successfully received HEADERS or DATA frame
• acquire it only when receive processing must enqueue a response or reset

Motivation

recv_headers and recv_data currently lock SendBuffer before processing an inbound frame, although the common successful path does not write to that buffer. Deferring the lock removes an unnecessary nested mutex acquisition and its cache traffic from the hot receive path.

The caller still holds the connection-wide Inner lock, so this patch does not remove the primary sender/driver serialization. It is intentionally a small lock-overhead optimization; oversized responses and receive errors still lock before queuing outbound frames.

Scope

The implementation is limited to one file. Existing integration coverage already exercises ordinary HEADERS/DATA receipt, oversized responses, and receive errors that emit RST_STREAM, so no test tied only to mutex placement was added.

Performance

In the initial isolated 256-stream, 65,536-frame run, median elapsed time moved from 369 ms to 355 ms (+3.9% throughput). Later Windows runs were scheduler-bimodal and placed the standalone result within roughly 1% in the fast cluster, so this should be treated as a modest hot-path improvement rather than a broad contention fix.

Validation

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