📝 Description

GraphQLWebSocketServer.handleSubscription pipes the inbound client-message
flow through flatMapMerge { ... } without an explicit concurrency argument,
so it falls back to the kotlinx DEFAULT_CONCURRENCY = 16. A single websocket
session holding more than 16 in-flight subscriptions silently back-pressures
every subsequent inbound message on the underlying flow — including ping,
complete, and additional subscribe messages — until one of the 16 in-flight
messages completes. The 17th-and-later subscribes therefore look hung from the
client's perspective even though the transport is healthy.

This change exposes the concurrency as a configurable value, threaded through
the three construction paths and both server configurations:

• GraphQLWebSocketServer — adds a final constructor parameter
  subscriptionConcurrency: Int = DEFAULT_WS_SUBSCRIPTION_CONCURRENCY
  (top-level const val = 16), used as the concurrency argument to
  flatMapMerge.
• KtorGraphQLWebSocketServer — forwards a matching parameter to the
  superclass constructor.
• KtorSubscriptionConfiguration — reads
  graphql.server.subscription.concurrency from ApplicationConfig with the
  same default; GraphQL.kt wires it into the Ktor handler.
• SubscriptionWebSocketHandler (Spring) — forwards a matching parameter to
  the superclass constructor.
• SubscriptionConfigurationProperties — adds
  subscriptionConcurrency: Int = DEFAULT_WS_SUBSCRIPTION_CONCURRENCY as a
  trailing, defaulted field (preserves data-class binary compatibility);
  SubscriptionGraphQLWsAutoConfiguration wires it through.

Defaults are unchanged (16), so existing callers see identical behaviour. Users
who hold many simultaneous subscriptions per session can now raise the value
(e.g. Int.MAX_VALUE) to avoid the back-pressure hang described in the issue.

A new regression test
(verify subscription flow honors configured concurrency) constructs the
in-memory subscription server with subscriptionConcurrency = 1 and sends two
back-to-back subscribe messages. Under the previous implicit default the two
subscriptions would interleave; with concurrency = 1 the assertion is that
all four responses for the first subscription id (3 × next + complete)
arrive before any response for the second, which is observable and would have
been impossible without exposing the knob.

The scope is intentionally narrow: only the plumbing and default are changed.
No change to TOO_MANY_REQUESTS handling, no change to graphql-ws protocol
semantics, no new public types beyond the constant and the trailing
parameters.

🔗 Related Issues

Closes #2018