chore(deps): pin transitive h2 dependency at minimum v0.4.13

[theJC]

Summary

Updates the transitive `h2` dependency `0.4.12 → 0.4.13`. Because `h2` was only present in `Cargo.lock` as a transitive dependency and not declared in any `Cargo.toml`, Renovate had no visibility into it and would never open a PR to bump it. This PR adds an explicit `h2 = "0.4.13"` declaration to `apollo-router/Cargo.toml`, which both enforces the minimum version floor immediately and brings `h2` under Renovate's management for future patch releases. There are no API or behavioral changes to router code; only the `Cargo.toml` declaration and `Cargo.lock` pin are affected.

Fixes in h2 0.4.13 and relevance to the router

Many Router customers use h2 as a client when connecting to subgraphs. All three fixes in this release are client-side.

Capacity deadlock under concurrent streams (hyperium/h2#860) — high relevance

Under concurrent load with `max_concurrent_streams` limits in effect, flow-control capacity could be assigned to streams still in `pending_open` state. Those streams could never consume the capacity, starving already-open streams and permanently freezing all outgoing traffic on the connection with no error surfaced. This is directly triggerable in the router: any subgraph behind Envoy or a gRPC backend advertises a `max_concurrent_streams` limit (Envoy defaults to 100), and under production load the router will routinely queue more concurrent requests than that limit allows.

OTel tracing span lifetime leak (hyperium/h2#868) — high relevance

The h2 `Connection` object captured the active tracing span at connection creation time as its parent, keeping that span alive for the entire lifetime of the pooled connection. Since the router wraps every subgraph request in an OpenTelemetry span and connections are pooled and long-lived, affected spans could linger indefinitely under sustained traffic — never being exported to the tracing backend and accumulating in memory.

Flow-control stall on padded DATA frames (hyperium/h2#869) — lower relevance for typical subgraphs, higher for connectors

Padding bytes in `DATA` frames were not being returned to the flow-control window, causing the connection window to drain to zero and permanently stalling downloads with no error. Typical GraphQL/gRPC subgraphs do not send padded frames, but router connectors calling arbitrary HTTP APIs (e.g., Google Cloud Storage or CDN-backed endpoints) can encounter this. Note: the uplink client currently uses reqwest without the `http2` feature, so it is not affected today — but should the uplink client be upgraded to use HTTP/2 (the primary uplink endpoint is GCP infrastructure, which is a known source of padded frames), this would become an additional exposure point.

Test plan

• Verify `cargo build` succeeds
• Verify `cargo nextest run` passes

🤖 Generated with Claude Code

[apollo-librarian]

✅ AI Style Review — No Changes Detected

No MDX files were changed in this pull request.

Review Log: View detailed log

This review is AI-generated. Please use common sense when accepting these suggestions, as they may not always be accurate or appropriate for your specific context.

[carodewig]

Thanks for this PR, @theJC! I've created a new PR with your changes (#9038) because of the issues with contributor PRs and will own getting it merged.