Tracking: Support Redis ACL

### Motivation

Kvrocks currently supports authentication through `requirepass` and namespace tokens, but it does not support Redis ACL users or fine-grained permission control.

**This is something the Kvrocks community has needed for a long time and is eager to have.**

This limits Redis compatibility and makes some production scenarios hard to secure, especially:

- read-only replication users
- command-level restrictions
- key-pattern restrictions
- per-user password management
- Redis client compatibility with ACL-aware workflows

Related discussions and issues:

- #2415
- https://github.com/apache/kvrocks/discussions/2938
- https://github.com/apache/kvrocks/discussions/3234
- https://github.com/apache/kvrocks/discussions/3382
- https://github.com/apache/kvrocks/discussions/2274

### Scope

This tracking issue splits Redis ACL support into smaller sub-issues. The initial goal is not to support every Redis ACL edge case at once, but to build a maintainable foundation that can evolve safely.

### High-Level Design Direction

- ACL users are managed by the admin user.
- Each ACL user maps to exactly one Kvrocks namespace.
- ACL data is persisted in storage instead of an external ACL file, so it can participate in replication.
- ACL rules are stored in a Redis-compatible `ACL SETUSER` rule-string form where practical.
- Runtime permission checks use parsed/cached ACL user objects.
- Command permissions should support command names, categories, and subcommands.
- Key/channel permissions should be enforced through the existing command key extraction path where possible.

### Initial Non-Goals

- Do not support deprecated Redis first-argument ACL rules.
- Do not require a full ACL file implementation in the first phase.
- Do not refactor every command family before the ACL foundation lands.
- Do not change public command behavior unrelated to ACL.

### Recommended implementation steps

- Finalize ACL semantics and namespace model
- https://github.com/apache/kvrocks/issues/3517
- Add ACL user model, parser, serializer, and in-memory cache
- Persist and replicate ACL users
- Integrate ACL authentication with `AUTH` and `HELLO AUTH`
- Add command and category permission checking
- Add key and channel pattern permission checking
- Implement the initial ACL command set
- Add ACL denial logging and `ACL DRYRUN`
- Add integration tests against Redis ACL-compatible behavior
- Add documentation and migration notes

### Acceptance Criteria

- Kvrocks can create, update, delete, and inspect ACL users.
- A non-admin ACL user can authenticate and is bound to the intended namespace.
- Command/category restrictions are enforced before command execution.
- Key-pattern restrictions are enforced for commands with known key specs.
- Replication can use a restricted ACL user where the required commands are allowed.
- ACL metadata is replicated consistently to replicas.
- Redis client workflows using `HELLO ... AUTH default ` remain compatible.
- Tests cover success and denial paths for authentication, command permissions, key permissions, and replication-sensitive cases.

Start with the ACL semantics and namespace model in #3517, then review the proposed entry points: ACL SETUSER rules, AUTH, HELLO AUTH, persistence, replication, and command key extraction. Done means ACL users can be managed, authenticated, namespace-bound, persisted and replicated, with command and key restrictions enforced and integration tests covering success and denial paths.

Written by the indexing model from the issue text.