Fix LRU RAM cache seen filter never engaging below 100% full

[phongn]

Summary

The tiered seen filter for the (default) LRU RAM cache never engaged at the documented fill levels: an integer-division bug made it engage only when the cache was 100% full, so a scan could pollute a partly-full cache.

Root cause

proxy.config.cache.ram_cache.use_seen_filter greater than 1 is documented to enable the seen filter once the cache is more than n% full (2 = 50%, 3 = 67%, 4 = 75%, up to 9 = 90%). The check was:

(bytes >= max_bytes * (1 - (1 / cache_config_ram_cache_use_seen_filter)))

cache_config_ram_cache_use_seen_filter is an int, so 1 / N is integer division and is 0 for every N > 1. The expression collapses to bytes >= max_bytes, i.e. the filter engages only at 100% full, and values 2–9 all behave identically.

Fix

Rewrite the comparison so it is exact in integer arithmetic and overflow-safe at realistic cache sizes:

(bytes * cache_config_ram_cache_use_seen_filter >= max_bytes * (cache_config_ram_cache_use_seen_filter - 1))

N=2 → ≥50%, N=3 → ≥67%, N=9 → ≥89%, as documented. (Only the LRU RAM cache uses the tiered percentage; CLFUS treats the knob as on/off and is unaffected.)

Test

Adds ram_cache_lru_seen_filter: with use_seen_filter = 2, fill the cache to ~60% then Put 20 unseen keys once each — above the 50% threshold the filter must reject them. Verified it fails on the old form (20/20 admitted at 60% full) and passes on the fix (0/20). The existing ram_cache regression test still passes.

Impact

Operators who set use_seen_filter to 2–9 to get scan resistance once the cache is partly full currently get none until it is completely full. This affects the default RAM cache (LRU).