feat: add compression module with zstd/gzip/lzma support

[cluster2600]

Summary

• Add Python compression module with zstd, gzip, and lzma backends
• Add streaming compression API for large datasets
• Enable RocksDB runtime compression codec detection (ZSTD → LZ4 → Snappy fallback)
• Extend CollectionSchema with compression configuration

Changes

Python

• python/zvec/compression.py — Core compression with pluggable backends
• python/zvec/compression_integration.py — Collection-level compression integration
• python/zvec/streaming.py — Streaming compression/decompression API
• python/zvec/model/schema/collection_schema.py — Compression config in schema
• python/zvec/__init__.py — Export compression module

C++

• src/db/common/rocbsdb_context.cc — Runtime detection of supported compression codecs using rocksdb::GetSupportedCompressions(), with fallback chain: ZSTD → LZ4 → Snappy → None

Tests

• python/tests/test_compression.py
• python/tests/test_compression_integration.py
• python/tests/test_schema_compression.py
• python/tests/test_streaming.py

Docs

• docs/COMPRESSION.md — Compression usage and configuration guide

Context

Split from #157 to isolate compression feature from CI and GPU work.

Test plan

• ruff lint and format pass
• clang-format passes on rocbsdb_context.cc
• Compression tests pass locally
• CI builds succeed (RocksDB compression fallback works on all platforms)

[zhourrr]

Thanks for putting together this compression proposal — we appreciate the effort and thought you've put into the design!

Our system is built around a C++ core, with Python (and other languages) serving as bindings to this vector search engine. Because of this, we generally aim to keep data-handling logic in the C++ engine, so all bindings benefit uniformly and behavior remains consistent. Are there particular use cases or constraints that make compression in Python necessary or advantageous?

I'm also curious about the expected benefit for vector data specifically. High-dimensional floating-point vectors are typically not very compressible with general-purpose algorithms. For storage efficiency, we already support quantizations (though they hurt recall), which are typically more effective for vectors than byte-level compression.

Any additional context you can share about the problem you're trying to solve would be very helpful!

[cluster2600]

Thanks for the thoughtful feedback @zhourrr! You raise valid points — keeping data-handling logic in the C++ core makes sense for consistency across all language bindings, and I agree that general-purpose compression has limited benefit for high-dimensional float vectors compared to the quantization you already support.

I'll close this one out. If compression at the C++ engine level ever becomes useful, happy to contribute there instead. Appreciate the review!