Seen in production on a node with 1GiB of heap: a deletion of a collection of snapshots involving one index with several megabytes of index metadata caused the node to go OOM. The issue in this case was ultimately the way that we invoke BlobStoreRepository.SnapshotsDeletion.IndexSnapshotsDeletion#determineShardCount concurrently across all 10 snapshot threads at once. Each thread ended up needing ~50MiB of heap to parse the metadata for this index, and the node couldn't cope. On smaller nodes I guess we shouldn't be doing this work with such high concurrency.

There's also a code comment indicating that we could make this metadata-loading process way more efficient:

Moreover as noted in #116379 there's a 2GiB limit for the list of blobs to clean up, but a small node would go OOME long before hitting that limit. We should impose a stricter limit on the memory usage for this data structure, ideally spilling the list to storage when reaching the limit but even just forgetting about some blobs would be better than having the node fail.

Relates #108278