feat: add VADD_BATCH command for bulk vector inserts

[kacy]

summary

• adds VADD_BATCH command that sends multiple vectors in a single round trip, eliminating per-vector protocol overhead for bulk inserts
• RESP3 syntax: VADD_BATCH key DIM n elem1 f32... elem2 f32... [METRIC|QUANT|M|EF]
• gRPC: VAddBatch(VAddBatchRequest) returns (IntResponse) with packed float entries
• max batch size: 10,000 vectors. all vectors validated upfront (NaN/inf rejects entire batch)
• AOF persistence reuses existing VAdd records (one per applied vector) — no new format needed

what was tested

• 10 new parser tests covering: basic 2-vector batch, options, single entry, empty entries, wrong arity, missing DIM keyword, DIM 0, DIM > max, insufficient floats, M/EF exceeds max
• 1 new shard test: to_aof_records_for_vadd_batch — 3 applied vectors produce 3 AofRecord::VAdd records
• cargo test -p ember-protocol — 330 tests pass
• cargo test -p emberkv-core --features vector — 351 tests pass (1 pre-existing failure in memory::tests::entry_overhead_not_too_small, unrelated)
• cargo build -p ember-server --features jemalloc,vector,grpc — clean build

design considerations

• DIM keyword in RESP3: required so the parser knows where each vector ends and the next element name begins. without it, an element name that happens to parse as a float would be ambiguous
• to_aof_record → to_aof_records refactor: changed return type from Option<AofRecord> to Vec<AofRecord> so VADD_BATCH can expand each applied vector into an individual VAdd record. all existing arms are mechanical Some(x) → vec![x] / None → vec![] changes
• no new AOF format: batch inserts replay as individual VAdd records on recovery. simpler than adding a batch record type and avoids version compatibility concerns
• upfront validation: all vectors checked for NaN/inf before any are inserted. memory estimated for the entire batch with one enforce_memory_limit call. partial insert on usearch error mid-batch is tracked for correct AOF recording