harden ember-protocol — vector dimension and HNSW parameter caps

[kacy]

summary

adds bounds checking to vector command parsing to prevent DoS through unbounded resource allocation:

• vector dimension cap: VADD and VSIM vectors now capped at 65,536 dimensions. this is generous for any real-world embedding model (OpenAI: 1,536, Cohere: 4,096) while preventing a client from sending million-dimension vectors that consume ~4MB each.
• HNSW parameter validation: M and EF parameters validated against a max of 1,024 before the u64 → u32 cast. values above this give no practical benefit for HNSW and waste memory. prevents silent truncation on values > u32::MAX.

what was tested

• all 296 ember-protocol unit tests pass
• 1 doc-test passes
• cargo clippy -p ember-protocol clean

design considerations

• the RESP3 parser already caps arrays at 1M elements, so the worst-case without this fix was ~1M f32 dimensions (~4MB per vector). the new 65,536 cap brings this to ~256KB which is reasonable.
• HNSW parameter cap of 1,024 is based on the algorithm literature: M values above ~48 and EF values above ~500 show diminishing returns in recall benchmarks.