feat: grpc server implementation

[kacy]

summary

implements the full grpc server for ember, sitting alongside RESP3 with its
own listener port. all commands route through the same sharded engine, so
behavior is identical regardless of protocol.

• grpc.rs: tonic service impl (~1200 LOC) covering strings, keys, lists,
  hashes, sets, sorted sets, vectors, server commands, and bidirectional
  pipeline streaming
• --grpc-port 6380 (default) and --no-grpc CLI flags behind grpc feature
• grpc listener spawns as a separate tokio task in both run() and
  run_concurrent(), sharing engine, server context, and slowlog
• vector commands return UNIMPLEMENTED when built without the vector feature
• tokio-stream added for bidirectional pipeline streaming

error mapping follows grpc conventions:

• WrongType → FAILED_PRECONDITION
• OutOfMemory → RESOURCE_EXHAUSTED
• shard unavailable → UNAVAILABLE
• generic errors → INTERNAL

no unwrap() or expect() anywhere. every match arm is covered.

what was tested

• cargo build -p ember-server --features grpc — compiles
• cargo build -p ember-server — no regression without feature
• cargo clippy -p ember-server --features grpc -- -D warnings — clean
• cargo test -p ember-server --features grpc — 43/43 pass
• cargo fmt --all --check — clean

design considerations

grpc service does not use a separate grpc_convert.rs file as originally
planned. each handler does its own response mapping inline, which keeps the
code simpler and more readable since the mappings are straightforward.

the pipeline rpc uses a spawned task with an mpsc channel rather than direct
stream processing. this allows the pipeline to process commands concurrently
while maintaining response ordering via the request id field.

auth interceptor is not yet implemented (planned for a follow-up). the grpc
listener currently relies on the same protection mechanisms as RESP3 (network
isolation, requirepass at the RESP3 level).