Add cross-cycle presence cache to reduce repair HeadObject calls

[RolfAris]

Summary

• Repair cycles call bucket.Attributes (HeadObject) for every locally-held CID. On S3-compatible backends, this is the dominant source of metadata API calls.
• Adds an imcache LRU cache (knownPresent, 500K entries, no TTL) that remembers confirmed-present keys across cycles. Non-cleanup cycles check the cache and skip Attributes on hit.
• Cleanup cycles (every 4th) call RemoveAll() and do full verification — they need ModTime for over-replication decisions and run blob integrity validation.
• Cache is populated after all validation and cleanup checks pass, so corrupt or about-to-be-deleted blobs are never cached.
• Populated on replicateToMyBucket writes. Invalidated on dropFromMyBucket and cleanup validation deletes.
• Scoped to the repair batch path only — haveInMyBucket and serving paths are unchanged.

Design notes

• Uses imcache with WithNoExpiration() and LRU eviction, consistent with the four existing caches on MediorumServer. No new dependencies.
• Blobs deleted outside mediorum (manual storage console, backend-side loss) remain cached until the next cleanup cycle clears and re-verifies everything. This is an accepted tradeoff — cleanup runs every 4th cycle and is authoritative.
• The knownPresent.Remove inside the cleanup validation delete block is currently unreachable due to a pre-existing bug where err is checked instead of errVal (see Fix two bugs in repairCid: dead cleanup validation and wrong polarity #175). It becomes live when Fix two bugs in repairCid: dead cleanup validation and wrong polarity #175 merges.
• repair_known_present counter tracks cache hits per cycle. known_present_size is logged at cycle completion.

[raymondjacobson]

nice little PR here! The once every 4 cycles cleanup makes sense to me.

we'll see how the 500k limit fares. it may be worth exposing this in a var because archive nodes that volunteer to store the whole catalog would make use of a larger cache too