Eviction sorts by highest access count (backwards for LRU)

## Summary

The eviction logic in `CleanupManager.cs` and `Shard.cs` appears to sort deletion candidates by **descending** access count, which would delete the **most** accessed items first - the opposite of LRU behavior.

## Code Locations

**Shard.cs:107-110:**
```csharp
.OrderBy(r => (byte)r.Flags)
.Select(r => new Tuple(r, getUsageCount(r.AccessCountKey)))
.OrderByDescending(t => t.Item2) // Highest access count first
.Select(t => (ICacheDatabaseRecord) t.Item1)
```

**CleanupManager.cs:184-189:**
```csharp
(await Database.GetDeletionCandidates(shard, deletionCutoff, creationCutoff, Options.CleanupSelectBatchSize, AccessCounter.Get))
.Select(r => // I'm confused, GetDeletionCandidates already does this sort...
new Tuple(
AccessCounter.Get(r.AccessCountKey), r))
.OrderByDescending(r => r.Item1) // Highest access count first (again)
.Select(r => r.Item2).ToArray();
```

Note the existing comment "I'm confused, GetDeletionCandidates already does this sort..." suggesting this was noticed before.

## Expected Behavior

For LRU eviction, items with the **lowest** access count should be deleted first. The sort should be `OrderBy` (ascending), not `OrderByDescending`.

## Questions

1. Is this intentional for some reason I'm not seeing?
2. Should both sorts be changed to ascending?
3. Why is the sort duplicated in both locations?

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start with the cited sections of Shard.cs and CleanupManager.cs, then trace GetDeletionCandidates and its callers to understand why candidate ordering appears in both places. Search for existing cache cleanup or eviction tests and run them. Done means the eviction path consistently selects the least-accessed records first without breaking the existing cleanup behavior.

Written by the indexing model from the issue text.