[kafka] Implement registry-backed ApiVersions API

### Parent issue

Part of #4185 — Kafka Protocols Compatibility: Basic Produce.

### Motivation

Kafka clients need an accurate list of supported API versions before using the server. Capability negotiation should be driven by implemented, registered handlers rather than by a list of placeholder APIs.

### Scope

- Implement ApiVersions using the capability registry from #4264.
- Advertise only registered, public capabilities and their supported version ranges.
- Connect the asynchronous dispatcher to the production Kafka request handler and replace the old switch/stubs.
- Cover supported and unsupported versions, invalid requests, error responses, and capability advertisement.

### Acceptance criteria

- [ ] ApiVersions returns the server's registered capabilities and version ranges.
- [ ] Unsupported versions and malformed requests produce the expected Kafka error responses.
- [ ] This stage registers only ApiVersions; Metadata is added by its own follow-up issue.
- [ ] Request/response buffer ownership remains correct and relevant Kafka tests and style checks pass.
- [ ] The focused implementation is reviewed and merged after its prerequisite.

### Dependencies

Depends on #4264.

### Out of scope

Metadata, Produce, authentication, schema conversion, Kafka CreateTopics/DeleteTopics, and automatic table creation.

### Implementation and review

Implementation PR: #4260.

The PR remains a draft while the framework dependency is pending. Its description includes an incremental comparison for reviewing this stage alone.

Start with prerequisite issue #4264 and the incremental comparison in draft PR #4260, then inspect the production Kafka request handler and relevant Kafka tests. Done means registered public capabilities and version ranges are advertised, invalid or unsupported requests return expected errors, buffer ownership remains correct, and style and focused tests pass.

Written by the indexing model from the issue text.