[SVS] Refactor SVS element size calculations and block size handling

[rfsaliev]

Describe the changes in the pull request

This pull request refactors and improves the way element sizes and block sizes are calculated and used in the SVS storage traits, enhancing clarity and modularity in the code. The changes introduce clearer separation between primary, residual, and secondary element sizes, update the block size calculation to use a new structure, and simplify related test logic.

Which issues this PR fixes

This PR fixes index size estimation issues for SVSIndex by using new blocksize_elements parameter introduced in intel/ScalableVectorSearch#344.

TODO:

• Update SVS shared library binary URLs

Main objects this PR modified

1. SVSIndex
2. SVS tests

Mark if applicable

• This PR introduces API changes
• This PR introduces serialization changes

---

Note

Medium Risk
Changes affect SVS memory layout, blocking, and size estimation for quantized indexes; risk is mitigated by test updates and a dependency bump rather than API changes.

Overview
SVS index size estimation and blocked storage are updated to match Intel ScalableVectorSearch v0.3.2 (shared library URLs in cmake/svs.cmake bumped from v0.3.1 to v0.3.2).

SVSBlockSize now returns svs::data::BlockingParameters with both byte block size and element-count block size (blocksize_elements from upstream #344), instead of a single PowerOfTwo.

For LVQ and LeanVec traits, element sizing is split into primary, residual, and secondary helpers; blocked allocators use the max of the relevant component sizes when computing blocks. Total element_size is the sum of those parts.

Tests: testSizeEstimation drops the old LVQ dimension fudge and uses 1% tolerance for per-block growth estimates; tiered runGCAPI sets blockSize to threshold/2 so deletes span at least two blocks (workaround for SVS keeping one empty block on shrink).

^{Reviewed by Cursor Bugbot for commit 7e7d646. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.13%. Comparing base (dd6879e) to head (7e7d646).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #980   +/-   ##
=======================================
  Coverage   97.12%   97.13%           
=======================================
  Files         141      141           
  Lines        8245     8260   +15     
=======================================
+ Hits         8008     8023   +15     
  Misses        237      237           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alonre24]

LGTM - did we confirm that there is no regression in terms of memory consumption in benchmarks?

[alonre24]

Do we want to merge it as it is (using the nightly version) or bump to an official svs release?

[rfsaliev]

@alonre24, now there is SVS v.0.3.2 release used in this change.
FYI: SVS v.0.3.2 = v.0.3.1 + LVQ exports required to compute 'Residual' element size.

[ethanglaser]

Note to Redis team: we dropped support for amazonlinux builds, so up to you on whether we keep this at the v0.3.0 or drop it entirely.

[ethanglaser]

I didn't realize my approval would trigger a merge - I'll leave that decision up to @alonre24 etc.