The throughput-controlled API key bitmap is sized to max_api_key()+1
(~69 entries, the standard Kafka range), but the three sites that consult
it indexed with .at(request_key). A request carrying an API key beyond the
standard range therefore threw std::out_of_range in the throttle path,
before the request reached the handler router. The error path treats that
as a short-read disconnect, so the connection is dropped instead of the
key being rejected as an unsupported API.

Guard the three sites with an explicit size check so out-of-range keys
fall through as not throughput-controlled, mirroring the bounds check
handler_for_key already applies to its dispatch table.

This also makes the reserved Redpanda API-key range (15000+) safe to
dispatch.

Kafka API keys are assigned sequentially by Apache and are still under
100 today. To leave room for future standard assignments and avoid
colliding with keys other Kafka implementations may already use, custom
Redpanda APIs start at 15000, well above the standard range;
DescribeRedpandaRoles is the first and takes that base key.

A key that high can't simply be added to the standard dispatch
structures. Kafka request routing uses three tables indexed directly by
API key and sized to the largest key present: the handler lookup table
(handler_interface), the flex-version map (flex_versions), and the
per-shard handler_probe vector. Registering key 15000 in them would grow
each to ~15000 mostly-empty entries, and because the probe vector is
per-shard, that waste is multiplied across cores.

So the Redpanda reserved range is kept separate. max_api_key() still
derives only from the standard request_types, leaving those three
structures sized to the standard range, and each site gains a second
table for the reserved range. That table is rebased, indexed by
key - redpanda_api_key_base, so its size tracks the span of the custom
range (one entry today). Standard keys take the existing path unchanged;
only keys at or above the base fall through to this secondary lookup.