Reclaim the snapshot a record stops naming

[MayCXC]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Closes #2164.

A snapshot is owned by the record that names it, so a record that stops naming one leaves it owned by nobody. Three paths let that happen and one of them disables the collector.

Registration that replaces a reference. Pulling or loading a reference that already exists replaces its record and leaves the replaced generation's unpacked snapshot owned by no image. Nothing collects those outside the delete and prune commands, so a machine that rebuilds or refreshes the same tags accumulates dead snapshots indefinitely; a week of image rebuilds on one machine held 28G this way, invisible to every per-run cleanup. The sweep now runs after every operation that lands records, using the same keep set the prune path uses, and its failure warns rather than failing the pull or load that carried it.

Removal. Registration over an existing reference was swept and removal was not, so every deleted image left its unpacked snapshot behind. That penalises the tidy caller: an integration run that deletes each image its builds register leaves a snapshot per build, and a suite of them fills a disk that the same suite without the tidying would not have.

One bad item stopping the pass. The sweep reads every image to learn which snapshot it claims, then removes the snapshots no image claims, and a failure anywhere in either loop abandoned the whole pass. One record from an interrupted pull, whose content the store no longer holds, stopped every snapshot from ever being reclaimed again for as long as that record existed; and one snapshot that would not remove abandoned the rest of the set and discarded the bytes already freed, so the caller was told nothing had been reclaimed when some of it had. Each image is read and each snapshot removed on its own terms now, with the error logged against the item that raised it. An image the store cannot read is one it cannot unpack or run either, so the snapshot that image would have claimed is not worth keeping the store full for.

Serialization. The service is an actor, and every await inside a store operation admits the next call, so a collection can overlap an in-flight landing: its keep set is computed without the arriving image, and the cleanup prunes blobs the landing is about to reference and sweeps the snapshot a container is about to attach. A lock held across each whole mutating operation admits one at a time, the way PodsService holds its lock across lifecycle operations. containerd guards the same window with leases: https://github.com/containerd/containerd/blob/main/docs/garbage-collection.md

An integration run here left 21G of unpacked filesystems for images nothing named, and the control plane then failed on the disk they took.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

Integration suite: 397 passed. Unit suite: 772 passed. make fmt, make check clean.