Fix download cache bloat and stale disk capacity reporting causing Diego cell disk full

[kart2bc]

• Read the Contributing document.

Summary

The Problem

Diego cells were hitting 90%+ disk usage while the rep kept reporting tens of GB available. Two independent bugs combined to cause this.

---

Bug 1 — Download cache grows past its 10 GB ceiling

Where: cacheddownloader/file_cache.go makeRoom()

How it worked before:
The cache enforced its size ceiling using only in-memory accounting — it tracked how many bytes it thought it had stored. Three things caused that number to drift below reality:

• If all entries were in use when a new download arrived, makeRoom() skipped eviction entirely but still added the new file — silently exceeding the ceiling
• GetDirectory() doubles entry.Size when both a .tar and its extracted .tar.d exist simultaneously. If the ref-count logic misfired, the doubling was never reversed — the in-memory tracker over-counted that entry, causing it to evict earlier than needed and allowing more real disk to be used than the ceiling allows
• These drifted sizes were saved to saved_cache.json on disk and reloaded on restart, carrying the error forward

Real-world result: /var/vcap/data/rep/shared/garden/download_cache grew to 46 GB while in-memory tracking reported < 10 GB.

Fix:
Added a minimumPartitionFreeBytes field (default 5 GB) and a FreeSpaceFunc that calls syscall.Statfs to read actual partition free space. makeRoom() now loops until both conditions are satisfied:

in-memory usage < maxSizeInBytes
AND
real partition free space >= minimumPartitionFreeBytes

This means even if the in-memory accounting has drifted, the real disk pressure triggers eviction as a safety net.

---

Bug 2 — Rep advertises stale disk capacity forever

Where: executor/depot/depot.go TotalResources()

How it worked before:
At rep startup, fetchCapacity() computed available disk once:

DiskMB = (80 GiB total − 10 GiB cache reservation − ~188 MiB overhead) = 71,492 MB

This number was frozen for the entire lifetime of the rep. Every scheduling decision the auctioneer made used this stale value. As the
download cache grew past its 10 GB reservation, TotalRethe auctioneer kept scheduling new containers onto anearly-full cell.

Real-world result: cfdot cell-states showed AvailableResources.DiskMB = 47,940 MB while the physical disk had only 7.6 GB free.

Fix:
TotalResources() now calls syscall.Statfs on the disk peturns a live DiskMB value. MemoryMB and Containersremain frozen (they don't change at runtime — only disk does).

---

Backward Compatibility

Breaking Change? No

[ameowlia]

This is a bug fix, but it is also a breaking change. Please make that clear in the PR description.