feat: PROTO.GETFIELD for field-level protobuf reads

[kacy]

summary

adds PROTO.GETFIELD key field_path — reads a single field from a stored protobuf value and returns it as a native RESP3 type. supports dot-separated nested paths (e.g., address.city).

return type mapping:

• string → Bulk
• int32/int64/uint32/uint64 → Integer
• bool → Integer (1/0)
• float/double → Bulk (formatted string)
• bytes → Bulk
• enum → Bulk (value name)
• message/list/map → Error (use PROTO.GET)

this is phase 2, PR 1 of the protobuf field-level access feature. field mutations (PROTO.SETFIELD, PROTO.DELFIELD) follow in the next PR.

what was tested

• unit tests for all scalar field types, default values, nested path traversal, nonexistent field errors, and empty path errors (7 new tests in schema.rs)
• command parse tests for valid commands, nested paths, and wrong arity (3 new tests in command.rs)
• integration tests covering sharded + concurrent modes: getfield_string, getfield_missing_key, getfield_wrong_type, getfield_nonexistent_field, getfield_default_value, concurrent_getfield_string (6 new integration tests)
• cargo clippy --workspace --features protobuf -- -D warnings clean
• cargo check without protobuf feature (no regressions)

design considerations

• field operations are server-side: the server decodes the stored blob using the schema registry, extracts the field, and converts to RESP3. no changes to shard or keyspace layers.
• resolve_field_path clones the DynamicMessage to avoid lifetime issues with nested traversal. acceptable overhead since this is a read-only decode operation.
• complex types (nested messages, repeated fields, maps) return errors directing clients to PROTO.GET for full deserialization — keeps the API surface clean and avoids ambiguous serialization choices.