Feature Request: Support CLIENT REPLY OFF/ON/SKIP subcommands

### Feature request type

enhancement

### Is your feature request related to a problem? Please describe

#### Problem

Garnet does not support the `CLIENT REPLY` subcommand. Sending `CLIENT REPLY OFF` returns:

```
(error) ERR unknown subcommand 'REPLY'. Try CLIENT HELP.
```

Redis has supported `CLIENT REPLY OFF|ON|SKIP` since version 3.2.

#### Why It Matters

`CLIENT REPLY OFF` is used to implement fire-and-forget pipelines — a common pattern for high-throughput bulk writes. The client sends a batch of commands without reading responses, relying on `CLIENT REPLY OFF` to suppress server replies entirely. This avoids both the
overhead of parsing responses and the risk of TCP backpressure from unread reply data accumulating in kernel buffers.

Without this support, bulk write pipelines that use `CLIENT REPLY OFF` will deadlock under Garnet. The server continues sending `+OK` replies for every command, the client never reads them, and eventually the TCP send buffer fills up. The server then blocks trying to write to the socket, while the client blocks trying to send more commands — a classic TCP deadlock.

This affects any client library or tool that relies on `CLIENT REPLY OFF` for pipelining, including:

- [`redis-cli --pipe`](https://redis.io/docs/latest/develop/use/cli/#mass-insertion) (Redis's built-in mass insertion mode)
- Custom bulk loaders and cache warmers
- Client libraries with fire-and-forget APIs

#### Reproduction

```
127.0.0.1:6379> CLIENT REPLY OFF
(error) ERR unknown subcommand 'REPLY'. Try CLIENT HELP.
```

For the deadlock scenario:

```
# In a pipeline, send:
CLIENT REPLY OFF
SET key1 value1
SET key2 value2
... (repeat ~100K times)
CLIENT REPLY ON
# Client hangs after ~66K-119K commands — server is blocked writing
# unread +OK responses, client is blocked writing new commands.
```

#### Current CLIENT Subcommand Support

Garnet already supports several `CLIENT` subcommands:

| Subcommand | Supported |
|------------|-----------|
| GETNAME | ✅ |
| ID | ✅ |
| INFO | ✅ |
| KILL | ✅ |
| LIST | ✅ |
| SETINFO | ✅ |
| SETNAME | ✅ |
| UNBLOCK | ✅ |
| REPLY | ❌ |

#### Reference

- Redis documentation: https://redis.io/docs/latest/commands/client-reply/
- `CLIENT REPLY` accepts three modes:
- `OFF` — suppress all replies until `ON` is sent
- `ON` — resume normal replies (this reply itself is sent)
- `SKIP` — suppress the reply for the next command only

### Describe the solution you'd like

Add support for CLIENT REPLY [OFF|ON|SKIP]

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Start by locating Garnet's existing CLIENT subcommand handling and the tests covering GETNAME, ID, INFO, or related commands. Trace how per-client reply behavior is represented, then add coverage for OFF, ON, and SKIP, including the pipeline behavior described in the issue. Done means valid CLIENT REPLY modes work and unsupported modes return an appropriate error without replies accumulating.

Written by the indexing model from the issue text.