perf: dispatch pipelined commands concurrently

[kacy]

summary

changes pipelined command processing from serial to concurrent dispatch. instead of awaiting each command before starting the next, all commands are dispatched to shards simultaneously using join_all.

rationale

for a pipeline of 16 commands, the old code did 16 sequential channel round-trips:

for frame in frames {
    let response = process(frame).await;  // serial
    responses.push(response);
}

the new code dispatches all 16 concurrently:

let futures: Vec<_> = frames.map(|f| process(f)).collect();
let responses = join_all(futures).await;  // parallel

this allows shards to process commands in parallel rather than one at a time.

benchmarks (GCP c2-standard-8)

test	before	after	change
GET P=16 (8 shards)	~1,069k	~1,126k	+5%
SET P=16 (8 shards)	~998k	~1,003k	~same

the improvement is modest because the channel overhead (mpsc send + oneshot reply) is still present for every command. multi-core scaling remains broken.

test plan

• verified functional correctness with redis-cli (SET, GET, MGET, MSET)
• benchmarked on GCP VM with redis-benchmark
• tested with 50 and 200 concurrent clients

next steps

to achieve true multi-core scaling, ember needs architectural changes:

1. sharded acceptors - one tokio runtime + TcpListener per core via SO_REUSEPORT
2. connection-local shards - connections pinned to shards, single-key ops bypass channels

the channel-per-request model is the fundamental bottleneck.