feat: CLIENT ID / SETNAME / GETNAME / LIST

[kacy]

summary

adds connection introspection commands for debugging active connections — who's connected, from where, what they named themselves.

• CLIENT ID — returns the unique monotonic connection ID (assigned at accept)
• CLIENT SETNAME name / CLIENT GETNAME — set/get a human-readable connection name
• CLIENT LIST — dumps all connected clients with id, addr, name, age

the client registry is a lightweight Arc<Mutex<HashMap<u64, ClientInfo>>> on ServerContext, only touched on accept, disconnect, and CLIENT commands. the mutex is never contended on the GET/SET hot path.

what's not included (follow-up)

• CLIENT KILL — needs cancellation tokens + select! changes
• idle time / cmd count in LIST — would require per-command updates on the hot path

what was tested

• 8 new protocol parsing tests: parse_client_id, parse_client_id_case_insensitive, parse_client_getname, parse_client_setname, parse_client_setname_missing_name, parse_client_list, parse_client_unknown_subcommand, parse_client_no_subcommand
• all 359 protocol tests pass
• all 114 CLI tests pass
• all 79 integration tests pass
• cargo clippy --workspace -- -D warnings clean
• cargo fmt --all clean

design considerations

• CLIENT commands are connection-local — resolved immediately in the connection handler, same as PING/ECHO. no shard routing, no AOF persistence.
• client IDs use AtomicU64::fetch_add(1, Relaxed) — monotonically increasing, unique per server lifetime.
• the format_client_list helper lives in server.rs as pub(crate) so both sharded and concurrent handlers can share it without duplication.
• ClientInfo stores addr, name, and connected_at — enough for debugging without touching the hot path.