[matrixarkai]

Re-opening a cache with a smaller capacity than the one that wrote the data is
an ordinary event: the device shrank, or the configuration did. Recovery
indexes what is on the device — and stopped there.

256 incompressible kibibyte blocks, written with 1 MiB of SSD room
recovered under a 64 KiB capacity, before	268,800 bytes, 256 blocks
the capacity it was given	65,536 bytes
recovered under a 64 KiB capacity, after	65,100 bytes, 62 blocks

Four times the bound, counted in the tier's own figures, with nothing on the
way to removing it. The next write would have begun evicting; a cache nobody
writes to again would have stayed there.

Recovery now ends by bringing both persistent tiers down to their capacities —
which is where a bound belongs, after the operation that filled them rather
than at the next write. This is the same guarantee as the pin release in the
previous change, on the other path that can leave a tier above its capacity.

The test checks the index, not only the figure

An eviction that drops a block but keeps its index entry leaves a key the cache
claims to hold and cannot serve. That is the failure this change would most
likely cause, so the test reads back every surviving key rather than
trusting the byte count.

The fixture writes incompressible bytes and says why: with a compressible value
the blocks shrink to forty-four bytes each, the smaller capacity is never
reached, and the test measures nothing. That trap has already cost this work
two measurements.

Planted

recovery left the tier holding 268800 bytes against a capacity of 65536

Gates on both feature arms: cargo fmt --check, clippy --all-targets -D warnings, the suites, the vocabulary check, and both reports with
--require-passed.

🤖 Generated with Claude Code