service: bound concurrent rate-limit requests

[NVGreg]

Problem

Slow cache calls can retain ShouldRateLimit handlers after callers cancel. Without configured bounds, more gRPC streams can keep arriving while that work is stuck.

Change

Add optional per-instance request admission, a cache-work deadline, and a per-connection gRPC stream cap. Calls above the admission limit fail immediately with ResourceExhausted, separate from an OVER_LIMIT quota decision. Add admission metrics, preserve HTTP caller contexts, and map service errors to HTTP status codes.

Runtime contract

MAX_CONCURRENT_REQUESTS, REQUEST_TIMEOUT, and GRPC_MAX_CONCURRENT_STREAMS all default to 0 (disabled); operators must set bounds explicitly. The gRPC cap applies per connection, not per instance or to HTTP /json. A conforming client waits for stream capacity or its own deadline; it does not get an immediate application overload response from the stream cap.

Admission capacity remains occupied until synchronous work and completion-metric recording return, even after caller cancellation. The deadline is a cancellation signal, not a guarantee that Radix promptly drains a response or that Redis stops a command already sent. Shadow mode does not override service failures; rollout must account for the caller's failure policy.

Validation

Focused server, settings, and service tests pass. The gRPC tests verify HTTP/2 SETTINGS and one-connection deadline/recovery behavior. The stalled-Redis test uses the real client against a loopback RESP fixture and verifies that a cancelled call retains its admission slot until backend work returns.