Performance regression in HTTP/2 codec server path in 5.1.0

### Version

5.1.0

### Context

Hi,

I noticed a possible HTTP/2 codec server performance regression after moving from Vert.x `5.0.12` to Vert.x `5.1.0`.

This is only about the **HTTP/2 codec implementation**, not the multiplex implementation.

Environment:

```text
Ubuntu Linux
Java 21
native epoll transport
```

Benchmark shape:

```text
h2load -n 5000000 -c 8 -m 128 -t 8 http://127.0.0.1:8080
```

Minimal h2c server returning a small fixed body.

Rough numbers on my machine:

```text
5.0.12:
usually around 2.15M req/s
often up to ~2.20M

5.1.0:
usually around 2.02M–2.10M
```

So the difference looks roughly like a 5–8% throughput drop in this synthetic HTTP/2 hot-path benchmark, and h2load reported request latency also gets worse.

I collected async-profiler CPU/allocation profiles. Allocation did not look significantly worse overall. CPU looked like a distributed overhead increase around the new HTTP/2 request/response path, especially around:

```text
HttpRequestHeaders validate/sanitize
HttpRequestHead / HttpResponseHead
HttpServerRequestImpl / HttpServerResponseImpl
DefaultHttp2ServerStream.writeHead
request dispatch / stream close handling
```

My current understanding is that this may be related to the HTTP/2 codec path now going through the generic HTTP stream/request/response model, while HTTP/1 still has specialized `Http1ServerRequest` / `Http1ServerResponse` classes.

Question: would it make sense for the HTTP/2 codec server path to also have a specialized request/response fast path, similar to HTTP/1, while keeping the generic stream model for HTTP/2 multiplex and HTTP/3?

I am not asking to revert the 5.1 HTTP stream architecture. I wanted to ask whether this performance tradeoff is intentional/acceptable, or whether a specialized HTTP/2 codec path would be considered if it can be done cleanly.