哪些镜像保留规则既能让容器镜像仓库保持精简，又不会删除仍在使用的镜像？

开放问题

（所引用的）Distribution 文档解释道：镜像层（layer）按内容地址只存储一份，并在各个清单（manifest）之间共享；通过 API 删除一个清单只会移除引用关系；随后垃圾回收会删除不再被任何清单引用的数据块（blob），这一过程以标记-清除（mark-and-sweep）方式运行，期间镜像仓库应处于只读状态。托管镜像仓库会将这一机制封装进生命周期规则中：（所引用的）ECR 指南描述了这样的策略——镜像在匹配规则后按规则优先级于大约 24 小时内过期，并建议在应用某项策略之前，先预览它将使哪些镜像过期。

文档没有说明的是：对于一个每次提交都构建镜像、按摘要（digest）部署、偶尔要在数周后回滚的团队来说，哪些规则是安全的：

• 基于时间或数量的过期规则（例如"删除超过 N 天的无标签清单""每个仓库只保留最近 N 个"），与能够感知部署状态、会去查询当前运行工作负载或发布记录所引用内容的规则，二者相比如何。
• 如何将拉取请求（pull request）和分支构建与发布构建区分开，使前者可以短期存在，而规则又绝不会误伤后者。
• 标签不可变（immutability）设置、镜像签名，或以引用方（referrer）形式附加的认证信息（attestation），是否会改变生命周期规则必须保留的内容。（所引用的）ECR 指南指出，被清单列表（manifest list）引用的镜像不会先于该列表本身过期，引用方工件（referrer artifact）会随其主体镜像自动过期；其他镜像仓库是否有相同行为，也是本问题想了解的一部分。
• 规则出错时会发生什么：用于回滚或取证所需的镜像是否曾被误删，又是如何恢复的？
• 这些规则最终把镜像仓库的增长速度控制在什么水平，促使采取这些规则的主要原因是存储成本还是拉取延迟？

有用的回答应包含什么

镜像仓库的类型及其保留机制；具体规则及其执行顺序；发布镜像与临时构建之间如何区分；这些规则已经不变地运行了多久；实施前后存储量的变化趋势；以及至少一次与该规则集相关的事故或险情。如果回答只是复述供应商的默认设置，应明确说明；来自超大规模集群的回答，也应指出哪些部分依赖于小团队所不具备的工具。