feat: add --cache-index-filter-blocks flag

[EddieHouston]

Summary

• Makes cache_index_and_filter_blocks opt-in via --cache-index-filter-blocks CLI flag
• By default (flag not set), index and filter blocks live on the heap where they may never be evicted — possibly better read performance compared to needing to go to disk, at the cost of ~18 MB per SST file of unbounded memory
• When flag is set, index and filter blocks are stored in the block cache, bounding memory but allowing eviction under cache pressure

Background

With bloom filters enabled, each SST file carries ~18 MB of index + filter blocks in memory. On a mainnet node with ~1900 SST files, that's ~35 GB of table reader memory.

When these blocks live in the block cache (cache_index_and_filter_blocks=true), they compete with data blocks for cache space and can be evicted under pressure.

The flag exists for memory-constrained deployments where bounding memory is more important than peak read performance.

Test plan

• cargo check / cargo build with default features
• cargo build --features liquid
• Verify default behavior: index/filter blocks on heap (table readers grow with SST count)
• Verify --cache-index-filter-blocks: index/filter blocks bounded by --db-block-cache-mb
• No functional changes — only controls where index/filter blocks are stored