Split IFileContentCache into domain and admin interfaces

[hooyao]

Problem

IFileContentCache in src/ZipDrive.Domain/Abstractions/IFileContentCache.cs currently mixes domain concerns with infrastructure/maintenance concerns in a single interface:

Domain concern (used by ZipVirtualFileSystem):

• ReadAsync(archivePath, entry, cacheKey, buffer, offset, ct)

Infrastructure/admin concerns (used by CacheMaintenanceService and CLI shutdown):

• EvictExpired()
• Clear()
• ProcessPendingCleanup(maxItems)
• DeleteCacheDirectory()
• CurrentSizeBytes, CapacityBytes, HitRate, EntryCount, BorrowedEntryCount

The Application layer (ZipVirtualFileSystem) only calls ReadAsync. The maintenance and metrics methods are only used by infrastructure (CacheMaintenanceService) and the CLI host. Having them on a Domain interface violates the dependency inversion principle — the Domain layer shouldn't define infrastructure lifecycle operations.

Proposed Solution

Split IFileContentCache into two interfaces:

1. IFileContentCache (Domain) — keep only ReadAsync
2. IFileContentCacheAdmin (Infrastructure) — maintenance methods and observable properties

FileContentCache would implement both. ZipVirtualFileSystem depends on IFileContentCache, while CacheMaintenanceService depends on IFileContentCacheAdmin.

Impact

• Low risk refactor — no behavior change
• Cleaner separation of concerns at the Domain boundary
• Makes it easier to mock IFileContentCache in Application-layer tests (only 1 method)

Affected Files

• src/ZipDrive.Domain/Abstractions/IFileContentCache.cs
• src/ZipDrive.Infrastructure.Caching/FileContentCache.cs
• src/ZipDrive.Cli/Program.cs (DI registration)
• src/ZipDrive.Cli/CacheMaintenanceService.cs
• Tests referencing the full interface