Support configuring http2_max_pending_accept_reset_streams

### Background

The underlying `hyper`/`h2` implementation already supports configuring
`http2_max_pending_accept_reset_streams`, but this option is currently not
exposed by Volo's gRPC server.

In our production environment, we frequently observe the following warning:

```text
recv_reset; remotely-reset pending-accept streams reached limit (20)
```

Representative logs:

```text
{"timestamp":"2026-07-15T10:13:08.670091417+08:00","level":"WARN","fields":{"message":"recv_reset; remotely-reset pending-accept streams reached limit (20)"},"target":"h2::proto::streams::recv"}

{"timestamp":"2026-07-15T10:13:08.682643952+08:00","level":"WARN","fields":{"message":"recv_reset; remotely-reset pending-accept streams reached limit (20)"},"target":"h2::proto::streams::recv"}

{"timestamp":"2026-07-15T10:13:08.758969319+08:00","level":"WARN","fields":{"message":"recv_reset; remotely-reset pending-accept streams reached limit (20)"},"target":"h2::proto::streams::recv"}
```

These warnings are repeatedly emitted under load, indicating that the default
limit (20) is insufficient for some workloads.

### Reference

Hyper exposes this configuration because of the discussion in:

https://github.com/hyperium/hyper/issues/2877

### Proposed API

Expose the configuration through the gRPC server builder, similar to the
existing HTTP/2 configuration methods.

```rust
pub fn http2_max_pending_accept_reset_streams(
mut self,
max: impl Into>,
) -> Self {
self.http2_config.max_pending_accept_reset_streams = max.into();
self
}
```

Store the value in `Http2Config`:

```rust
pub(crate) max_pending_accept_reset_streams: Option,
```

with the default value:

```rust
max_pending_accept_reset_streams: None,
```

Finally, propagate the configuration into Hyper:

```rust
server
.http2()
// ...
.max_pending_accept_reset_streams(
self.http2_config.max_pending_accept_reset_streams,
);
```

### Benefits

- Allows applications to tune the limit for workloads with frequent HTTP/2 stream resets.
- Keeps the current behavior unchanged by default.
- Aligns Volo with the underlying Hyper API.
- The implementation is straightforward and fully backward compatible.

Start at the gRPC server builder's existing HTTP/2 configuration methods and the Http2Config definition. Trace the configuration into the Hyper server setup, then verify that the new option is forwarded and that the default behavior remains unchanged.

Written by the indexing model from the issue text.